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Chapter 1 


Overview 


This document outlines the OpenGL ES 2.0 specification. OpenGL ES 2.0 implements the Common profile 
only. The fixed point (signed 16.16) data type is supported for vertex attribute arrays only. Shader uniform 
variables and command parameters no longer support fixed point in order to simplify the API and also 
because the fixed point variants do not offer any additional performance. The OpenGL ES 2.0 pipeline is 
described in the same order as in the OpenGL specification. The specification lists supported commands 
and state, and calls out commands and state that are part of the full (desktop) OpenGL specification but 
not part of the OpenGL ES 2.0 specification. This specification is not a standalone document describing 
the detailed behavior of the rendering pipeline subset and API. Instead, it provides a concise description of 
the differences between a full OpenGL renderer and the OpenGL ES renderer. This document is defined 
relative to the OpenGL 2.0 specification. 

Starting with revision 2.0.22, a standalone document titled OpenGL ES Common Profile Specification 
(Full Specification) has been derived from the OpenGL 2.0 specification. The Full Specification is the 
authoritative definition of OpenGL ES 2.0. This document, the Difference Specification, will continue to be 
maintained as a quick reference, and to enable direct comparisons with OpenGL 2.0. 

This document specifies the OpenGL ES renderer. A companion document defines one or more bindings 
to window system/OS platform combinations analogous to the GLX, WGL, and AGL specifications. ! 


1.1 Conventions 


This document describes commands in the identical order as the OpenGL 2.0 specification. Each section 
corresponds to a section in the full OpenGL specification and describes the disposition of each command 
relative to this specification. Where necessary, the OpenGL ES 2.0 specification provides additional clarifi- 
cation of the reduced command behavior. 

Each section of the specification includes tables summarizing the commands and parameters that are re- 
tained. Several symbols are used within the tables to indicate various special cases. The symbol { indicates 
that an enumerant is optional and may not be supported by an OpenGL ES 2.0 implementation. The super- 
script + indicates that the command is supported subject to additional constraints described in the section 
body containing the table. 


g Additional material summarizing some of the reasoning behind certain decisions is included as an 
annotation at the end of each section, set in this typeface. a 





'See the Khronos Native Platform Graphics Interface specification. 


Chapter 2 


OpenGL Operation 


The significant change in the OpenGL ES 2.0 specification is that the OpenGL fixed function transformation 
and fragment pipeline is not supported. Other features that are not supported are that commands cannot be 
accumulated in a display list for later processing, and the first stage of the pipeline for approximating curve 
and surface geometry is eliminated. 


m OpenGL ES 2.0 is part of a wider family of OpenGL-derived application programming interfaces. 
As such, it shares a similar processing pipeline, command structure, and the same OpenGL name 
space. Where necessary, extensions are created to optionally support existing OpenGL 2.0 function- 
ality or to augment the existing OpenGL 2.0 functionality. OpenGL ES-specific extensions play a role 
in OpenGL ES similar to that played by OpenGL ARB extensions relative to the OpenGL specifica- 
tion. OpenGL ES-specific extensions are either precursors of functionality destined for inclusion in 
future core revisions, or formalization of important but non-mainstream functionality. 

Extension specifications are written relative to the full OpenGL specification so that they can also 
be added as extensions to an OpenGL 2.0 implementation and so that they are easily adapted 
to functionality enhancements that are drawn from the full OpenGL specification. Extensions that 
are part of the core do not have extension suffixes, since they are not extensions, though they are 
extensions to OpenGL 2.0. a 


2.1 OpenGL Fundamentals 


Commands and tokens continue to be prefixed by gl and GL_. The wide range of support for differing data 
types (8-bit, 16-bit, 32-bit and 64-bit; integer and floating-point) is reduced wherever possible to eliminate 
non-essential command variants and to reduce the complexity of the processing pipeline. Double-precision 
floating-point parameters and data types are eliminated completely, while other command and data type 
variations are considered on a command-by-command basis and eliminated when appropriate. Fixed point 
data types have also been added where appropriate. 

OpenGL ES interacts with two classes of framebuffers: window-system-provided framebuffers and 
application-created framebuffers. There is always one window-system-provided framebuffer, while application- 
created framebuffers can be created as desired. These two types of framebuffer are distinguished primarily 
by the interface for configuring and managing their state. 

The effects of OpenGL ES commands on the window-system-provided framebuffer are ultimately con- 
trolled by the window-system that allocates framebuffer resources. It is the window-system that determines 
which portions of this framebuffer OpenGL ES may access at any given time and that communicates to 
OpenGL ES how those portions are structured. Therefore, there are no OpenGL ES commands to configure 
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the window-system-provided framebuffer. Similarly, display of framebuffer contents on a CRT monitor or 
LCD panel (including the transformation of individual framebuffer values by such techniques as gamma 
correction) is not addressed by OpenGL ES. Framebuffer configuration occurs outside of OpenGL ES in 
conjunction with the window-system. 

The initialization of an OpenGL ES context itself occurs when the window-system allocates a window 
for OpenGL ES rendering and is influenced by the state of the window-system-provided framebuffer. 


2.1.1 Fixed-Point Computation 


The OpenGL ES 2.0 specification supports fixed-point vertex attributes using a 32-bit two’s-complement 
signed representation with 16 bits to the right of the binary point (fraction bits). The OpenGL ES 2.0 
pipeline requires the same range and precision requirements as specified in Section 2.1.1 of the OpenGL 
2.0 specification. 


2.2 GL State 


The OpenGL ES 2.0 specification retains a subset of the client and server state described in the full OpenGL 
specification. The separation of client and server state persists. Section 6.2 summarizes the disposition of 
all state variables relative to the specification. 


2.3. GL Command Syntax 


The OpenGL command and type naming conventions are retained identically. A new type fixed is added. 
Commands using the suffixes for the types: byte, ubyte, short, and ushort are not supported. The 
type double and all double-precision commands are eliminated. The result is that the OpenGL ES 2.0 
specification uses only the suffixes ’f’, and ’i’. 


2.4 Basic GL Operation 


The basic command operation remains identical to OpenGL 2.0. The major differences from the OpenGL 
2.0 pipeline are that commands cannot be placed in a display list; there is no polynomial function evaluation 
stage; the fixed function transformation and fragment pipeline is not supported; and blocks of fragments 
cannot be sent directly to the individual fragment operations. 


2.5 GL Errors 


The full OpenGL error detection behavior is retained, including ignoring offending commands and setting 
the current error state. In all commands, parameter values that are not supported are treated like any other 
unrecognized parameter value and an error results, i.e., INVALID_ENUM or INVALID_VALUE. Table 2.1 lists 
the errors. 

The command GetError is retained to return the current error state. As in OpenGL 2.0, it may be 
necessary to call GetError multiple times to retrieve error state from all parts of the pipeline. 








g Well-defined error behavior allows portable applications to be written. Retrievable error state allows 
application developers to debug commands with invalid parameters during development. This is an 
important feature during initial deployment. a 


4 OpenGL Operation 



































OpenGL 2.0 Common 
NO_ERROR V 
INVALID_ENUM V 
INVALID_VALUE e, 
INVALID_OPERATION V 











STACK_OVERF LOW = 
STACK_UNDERF LOW 
























































OUT_OF_MEMORY JV 

TABLE_TOO_LARGE = 
Table 2.1: Error Disposition 

OpenGL 2.0 Common 

enum GetError (void) v 














2.6 Begin/End Paradigm 


OpenGL ES 2.0 draws geometric objects exclusively using vertex arrays. The OpenGL ES 2.0 specification 
supports user defined vertex attributes only. Support for vertex position, normals, colors, texture coordinates 
is removed since they can be specified using vertex attribute arrays. 

The associated auxiliary values for user defined vertex attributes can also be set using a small subset of 
the associated attribute specification commands described in Section 2.7. 

Since the commands Begin and End are not supported, no internal state indicating the begin/end state is 
maintained. 

The POINTS, LINES, LINE_STRIP, LINE_LOOP, TRIANGLES, TRIANGLE_STRIP, and TRIANGLE-_FAN 
primitives are supported. The QUADS, QUAD_STRIP, and POLYGON primitives are not supported. 























Color index rendering is not supported. Edge flags are not supported. 





OpenGL 2.0 Common 
void Begin (enum mode) - 
void End (void) — 
void EdgeFlag[v] (T flag) — 


























m The Begin/End paradigm, while convenient, leads to a large number of commands that need to 
be implemented. Correct implementation also involves suppression of commands that are not legal 
between Begin and End. Tracking this state creates an additional burden on the implementation. 
Vertex arrays, arguably can be implemented more efficiently since they present all of the primitive 
data in a single function call. Edge flags are not included, as they are only used when drawing 
polygons as outlines and support for PolygonMode has not been included. 


Quads and polygons are eliminated since they can be readily emulated with triangles and it reduces 
an ambiguity with respect to decomposition of these primitives to triangles, since it is entirely left to 
the application. Elimination of quads and polygons removes special cases for line mode drawing 
requiring edge flags (should PolygonMode be re-instated). Q 
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2.7 Vertex Specification 


The OpenGL ES 2.0 specification does not include the concept of Begin and End. Vertices are specified 
using vertex arrays exclusively. 

Setting generic vertex attribute zero no longer specifies a vertex. Setting any generic vertex attribute, 
including attribute zero, updates the current values of the attribute. The state required to support vertex 
specification consists of MAX _VERTEX_ATTRIBS four-component floating-point vectors to store generic 
vertex attributes. 

There is no notion of a current vertex, so no state is devoted to vertex coordinates. The initial values for 
all generic vertex attributes, including vertex attribute zero, are (0, 0, 0, 1). 





OpenGL 2.0 Common 


void Vertex {234} {sifd}[v] (I. coords) - 
void Normal3{bsifd}[v] (T coords) — 
void TexCoord{1234}{sifd}[v] (IT coords) - 
void MultiTexCoord {1234} {sifd}[v] (enum texture, T coords) - 
void Color{34}{bsifd ub us ui}[v] (I components) - 
void FogCoord{fd}[v] (T coord) _ 
void SecondaryColor3{bsifd ub us ui}[v] (T components) - 
void Index{sifd ub}[v] (T_ components) — 
void VertexA ttrib{1234}f[v] (uint indx, T values) VY 
void VertexA ttrib{1234} {sd}[v] (uint indx, T values) - 
void VertexAttrib4{bsid ubusui}v (uint indx, T values) - 
void VertexAttrib4N{bsi ubusui}[v] (uint indx, T values) — 





















































mw Generic per-primitive attributes can be set using the (VertexAttrib*) entry points. The most general 
form of the floating-point version of the command is retained to simplify addition of extensions or 
future revisions. Since these commands are unlikely to be issued frequently, as they can only be 
used to set (overall) per-primitive attributes, performance is not an issue. 


OpenGL ES 2.0 supports the RGBA rendering model only. One or more of the RGBA component 
depths may be zero. Color index rendering is not supported. a 


2.8 Vertex Arrays 


Vertex data is specified using VertexAttribPointer. Pre-defined vertex data arrays such as vertex, color, 
normal, texture coord arrays are not supported. Color index and edge flags are not supported. Both in- 
dexed and non-indexed arrays are supported, but the InterleavedArrays and ArrayElement commands are 
not supported. 


Indexing support with ubyte and ushort indices is supported. Support for uint indices is not required 
by OpenGL ES 2.0. If an implementation supports uint indices, it will export the OES_element_index_— 
uint extension. 








OpenGL 2.0 Common 


void VertexPointer (int size, enum type, sizei stride, 











const void xptr) 
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OpenGL 2.0 


void NormalPointer (enum type, sizei stride, const void 
xptr) 


Common 





void ColorPointer (int size, enum type, sizei stride, 
const void xptr) 





void TexCoordPointer (int size, enum type, sizei stride, 
const void xptr) 





void SecondaryColorPointer (int size, enum type, sizei 
stride, void x*ptr) 





void FogCoordPointer (enum type, sizei stride, void *ptr) 





void EdgeFlagPointer (sizei stride, const void xptr) 





void IndexPointer (enum type, sizei stride, const void 
*xptr) 





void ArrayElement (int i) 








void VertexAttribPointer (uint index, int size, enum type, boolean normalized, 


sizei stride, const void *ptr) 















































size = 1,2,3,4, type = BYTE 4 
size = 1,2,3,4, type = UNSIGNED_BYTE 4 
size = 1,2,3,4, type = SHORT JV 
size = 1,2,3,4, type = UNSIGNED_SHORT J 
size = 1,2,3,4, type = INT - 
size = 1,2,3,4, type = UNSIGNED_INT - 
size = 1,2,3,4, type = FLOAT JV 
size = 1,2,3,4, type = FIXED 4 
void DrawArrays (enum mode, int first, sizei count) 
mode = POINTS, LINES, LINE_STRIP, LINE_LOOP V 
mode = TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN JV 














mode = QUADS, QUAD_STRIP, POLYGON 








void DrawElements (enum mode, sizei count, enum type, cons 
mode = POINTS, LINES, LINE_STRIP, LINE_LOOP 

mode = TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN 

mode = QUADS, QUAD_STRIP, POLYGON 

type = UNSIGNED_BYTE, UNSIGNED_SHORT 

type = UNSIGNED_INT 



























































E 


t void *indices) 


V 
V 





void MultiDrawArrays (enum mode, int «first, sizei 
*xcount, sizei primcount) 





void MultiDrawElements (enum mode, sizei *count, enum 


type, void **indices, sizei primcount) 





void InterleavedArrays (enum format, sizei stride, const 
void xpointer) 





void DrawRangeElements (enum mode, uint start, uint end, 


sizei count, enum type, const void *xindices) 





void ClientActiveTexture (enum texture) 





void EnableClientState (enum cap) 








void DisableClientState (enum cap) 
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OpenGL 2.0 Common 
void EnableVertexAttribArray (uint index) V4 
void DisableVertexAttribArray (uint index) V 





™@ Float types are supported for all-around generality, short, ushort, byte and ubyte types 
are supported for space efficiency. Support for indexed vertex arrays allows for greater reuse of 


coordinate data between multiple faces, that is, when the shared edges are smooth. 


The OpenGL 2.0 specification defines the initial type for the vertex attribute arrays to be FLOAT. a 


2.9 Buffer Objects 


The vertex data arrays described in Section 2.8 are stored in client memory. It is sometimes desirable to 
store frequently used client data, such as vertex array data in high-performance server memory. OpenGL 
ES buffer objects provide a mechanism that clients can use to allocate, initialize and render from memory. 


Buffer objects can be used to store vertex array and element index data. 
MapBuffer and UnmapBuffer functions are not required. 













































































OpenGL 2.0 Common 
void BindBuffer (enum target, uint buffer) 4 
void DeleteBuffers (sizei n, const uint xbuffers) vA 
void GenBuffers (sizei n, uint xbuffers) WA 
void BufferData (enum target, sizeiptr size, const void / 
xdata, enum usage) 
void BufferSubData (enum target, intptr offset, sizeiptr J 
size, const void *data) 
void *MapBuffer (enum target, enum access) -— 
boolean UnmapBuffer (enum target) - 
Name Type Initial Value | Legal Values 
BUFFER_SIZE integer 0 any non-negative integer 
BUFFER_USAGE enum STATIC_DRAW | STATIC_DRAW, DYNAMIC_DRAW, STREAM_DRAW 

















Table 2.2: Buffer object parameters and their values 


= MapBuffer and UnmapBuffer functions are not required because it may not be possible for an 
application to read or get a pointer to the vertex data from the vertex buffers in server memory. 


BufferData and BufferSubData define two new types that will work well on 64-bit systems, analogous 
to C’s “intptr_t’. The new type ”GLintptr” should be used in place of GLint whenever it is expected 
that values might exceed 2 billion. The new type ”GLsizeiptr” should be used in place of GLsizei 
whenever it is expected that counts might exceed 2 billion. Both types are defined as signed integers 
large enough to contain any pointer value. As a result, they naturally scale to larger numbers of bits 
on systems with 64-bit or even larger pointers. a 
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2.10 Rectangles 


The commands for directly specifying rectangles are not supported. 





OpenGL 2.0 Common 
void Rect{sifd} (T x1, T yl, T x2, T y2) - 
void Rect{sifd}v (T v1[2], T v2[2]) - 























mg The rectangle commands are not used enough in applications to justify maintaining a redundant 
mechanism for drawing a rectangle. a 


2.11. Coordinate Transformations 


The fixed function transformation pipeline is no longer supported. The application can compute the neces- 
sary matrices (can be the combined modelview and projection matrix, or an array of matrices for skinning) 
and load them as uniform variables in the vertex shader. The code to compute transformed vertex will now 
be executed in the vertex shader. 

The Viewport command is supported since the viewport transformation happens after the programmable 
vertex transform and is a fixed function. 





OpenGL 2.0 Common 
void DepthRange (clampd n, clampd f) 





void DepthRangef (clampf n, clampf f) 





<]< 


void Viewport (int x, int y, sizei w, sizei h) 








void MatrixMode (enum mode) - 
void LoadMatrixf (float m[16]) 
void LoadMatrixd (double m[16]) = 
void MultMatrixf (float m[16]) — 
void MultMatrixd (double m[16]) = 
void LoadTransposeMatrix{fd} (T m[16]) - 
void MultTransposeMatrix{fd} (T m[16]) - 
void LoadIdentity (void) - 
void Rotatef (float angle, float x, float y, float z) — 
void Rotated (double angle, double x, double y, double 
Zz) 

void Scalef (float x, float y, float z) - 
void Scaled (double x, double y, double z) - 
void Translatef (float x, float y, float z) - 
void Translated (double x, double y, double z) — 
void Frustum (double 1, double r, double b, double t, 
double n, double f) 

void Ortho (double 1, double r, double b, double t, 
double n, double f) 

void Frustumf (float 1, float r, float b, float t, float 
n, float £f) 
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OpenGL 2.0 Common 
void Orthof (float 1, float r, float b, float t, float 

n, float f) 7 
void ActiveTexture (enum texture) V 





void PushMatrix (void) - 
void PopMatrix (void) - 
void Enable/Disable (RESCALE_NORMAL) - 
void Enable/Disable (NORMALIZE) - 
void TexGen{ifd}[v] (enum coord, enum pname, T param) — 






































void GetTexGen{ifd}v (enum coord, enum pname, T *params) - 
void Enable/Disable (TEXTURE_GEN_{STRQ}) - 



































m Features such as texture coordinate generation, normalization and rescaling of normals etc. can 
now be implemented inside a vertex shader, and are therefore not needed. 0 
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2.12 Clipping 


Clipping against the viewing frustum is supported; however, separate user-specified clipping planes are not 
supported. 

The following modifications describes how lines and points are clipped in OpenGL ES 2.0 

If the primitive is a point, then clipping discards it if it lies outside the near or far clip plane; otherwise, 
it is passed unchanged. If the primitive is a line segment, and a part of it lies outside the space between the 
near and the far plane, the line is clipped and new vertex coordinates are computed for one or both vertices. 
A clipped line segment endpoint lies on both the original line segment and on either the near or the far 
clipping plane. If the line segment lies completely between the two planes, it is passed unchanged. 





OpenGL 2.0 Common 


void ClipPlane (enum plane, const double *equation) - 





void GetClipPlane (enum plane, double *equation) - 
void Enable/Disable (CLIP _PLANE{0-5}) - 




















mw User-specified clipping planes are used predominately in engineering and scientific applications. 
User clip planes can be emulated by calculating the dot product of the user clip plane with the vertex 
position in eye space in the vertex shader. This term can be defined as a varying variable. The 
fragment shader can reject the pixel based on the value of this term. Depending on the float pre- 
cision types supported in a fragment shader, there may be clipping artifacts because of insufficient 
precision. a 


2.13. Current Raster Position 


The concept of the current raster position for positioning pixel rectangles and bitmaps is not supported. 
Current raster state and commands for setting the raster position are not supported. 





OpenGL 2.0 Common 


RasterPos{2,3,4} {sifd}[v] (T coords) - 
WindowPos {2,3} {sifd}[v] (T coords) - 


























m Bitmaps and pixel image primitives are not supported so there is no need to specify the raster 
position. a 


2.14 Colors and Coloring 


The OpenGL 2.0 fixed function lighting model is no longer supported. 





OpenGL 2.0 Common 
void FrontFace (enum mode) V 
void Enable/Disable (LIGHTING) - 
void Enable/Disable (LIGHT{0-7}) - 
void Materialf[v] (enum face, enum pname, T param) — 























void Materiali[v] (enum face, enum pname, T param) - 














void GetMaterialfv (enum face, enum pname, T *xparams) — 
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OpenGL 2.0 Common 


void GetMaterialiv (enum face, enum pname, T *params) — 





void Lightf[v] (enum light, enum pname, T param) - 





void Lighti[v] (enum light, enum pname, T param) - 





void GetLightfv (enum light, enum pname, T *params) - 








void GetLightiv (enum light, enum pname, T *params) - 





void LightModelf[v] (enum pname, T param) - 





void LightModeli[v] (enum pname, T param) - 
void Enable/Disable (COLOR_ MATERIAL) - 
void ColorMaterial (enum face, enum mode) — 
void ShadeModel (enum mode) — 


























mw The OpenGL 2.0 or any user defined lighting can be implemented by writing appropriate vertex 
and/or pixel shaders. 


ShadeModel is no longer supported as flat vs. gouraud shading only applied to the predefined color 
vertex attribute. Predefined vertex attributes are not supported by OpenGL ES 2.0. a 


2.15 Vertex Shaders 


OpenGL 2.0 supports the fixed function vertex pipeline and a programmable vertex pipeline using vertex 
shaders. OpenGL ES 2.0 supports the programmable vertex pipeline only. OpenGL ES 2.0 allows applica- 
tions to describe operations that occur on vertex values and their associated data by using a vertex shader. 


OpenGL ES 2.0 provides interfaces to directly load pre-compiled shader binaries, or to load the shader 
sources and compile them. An OpenGL ES implementation must support one of these methods for load- 
ing shaders. A query of boolean value SHADER_COMPILER can be used to determine if the OpenGL ES 
implementation supports a shader compiler. 








2.15.1 Loading and Compiling Shader Sources 


The ShaderSource command loads source code into a vertex or a fragment shader object. Once the source 
code for a shader has been loaded, a shader object can be compiled using the CompileShader command. A 
string that contains information about the last compilation attempt on a shader object, called the info log, 
can be obtained with the GetShaderInfoLog command. The GetShaderSource command returns the shader 
source for the specified shader object. 


The ReleaseShaderCompiler command allows the OpenGL ES implementation to release the resources 
allocated by the shader compiler. This is a hint from the application and is no indicator that the compiler 
will not be used in the future. If shader sources are loaded and compiled after ReleaseShaderCompiler has 
been called, the CompileShader call is supposed to successfully compile the shaders provided there are no 
errors in the shader source(s). 


The command 


void GetShaderPrecisionFormat(enum shadertype, enum precisiontype, int *range, int *precision) 


returns the range and precision for different numeric formats supported by the shader compiler. shadertype 
must be VERTEX_SHADER or FRAGMENT_SHADER. precisiontype must be one of LOW_FLOAT, MEDIUM_- 
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FLOAT, HIGH-FLOAT, LOW_INT, MEDIUM_INT or HIGH_INT. range points to an array of two integers in 
which encodings of the format’s numeric range are returned. If mzn and maz are the smallest and largest 
values representable in the format, then the values returned are defined to be 





range|0| = [log2(|min) | 


range|[1] = |log2(|maz|) | 


precision points to an integer in which the log2 value of the number of bits of precision of the format is 
returned. If the smallest representable value greater than 1 is 1+ ¢, then *precision will contain |—loge(e) |, 
and every value in the range 


[=oraren| grangeltt 


can be represented to at least one part in 2*?"¢°S!°". For example, an IEEE single-precision floating-point 
format would return range|0] = 127, range|1] = 127, and *precision = 23, while a 32-bit twos- 
complement integer format would return range|0] = 31, range[1] = 30, and *precision = 0. 

The minimum required precision and range for formats corresponding to the different values of preci- 
siontype are described in section 4.5 of the OpenGL ES Shading Language specification. 

If high precision floating-point is not supported in fragment shaders, calling GetShaderPrecisionFormat 
with a precisiontype of HIGH_-FLOAT will return zero for range[0], range[1], and *precision. 

If the value of SHADER_COMPILER is not TRUE, then the error INVALID_OPERATION is generated. 














2.15.2 Shader Binaries 


The ShaderBinary command can be used to load precompiled shader binaries. 


void ShaderBinary(sizei count, const uint *shaders, enum binaryformat, const void *binary, sizei length) 


This call takes a list of count shader handles described by shaders. Each shader handle refers to a unique 
shader type i.e. a vertex shader or a fragment shader. The binary argument points to length bytes of pre- 
compiled binary code. This provides the ability to individually load binary vertex, or fragment shaders or 
load an executable binary that contains the optimized pair of vertex and fragment shaders stored in the same 
binary. 

The binary image will be decoded according to the specification defining the binaryformat token. A 
binary data that does not match the specified binaryformat will result in an INVALID_VALUE error. The bits 
that represent the binary is implementation specific. An INVALID_OPERATION error is generated if any of 
the handles in shaders is not a valid shader object created with CreateShader, or if more than one of the 
handles refers to the same type of shader (vertex or fragment shader.) If ShaderBinary failed, GetError can 
be used to return the appropriate error. A failed binary load does not restore the old state of shaders for 
which the binary was being loaded. 








Queries of values NUM_SHADER_BINARY_FORMATS and SHADER_BINARY_FORMATS return the number 
of shader binary formats and the list of shader binary format values supported by an OpenGL ES implemen- 
tation 








Note that if shader binary interfaces are supported, then an OpenGL ES implementation may require 
that an optimized pair of vertex and fragment shader binaries that were compiled together be specified to 
LinkProgram. Not specifying an optimized pair may result in the LinkProgram call to fail. 
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2.15.3. Program Objects 


The shader objects that are to be used by the programmable stages of OpenGL ES are collected together to 
form a program object. The programs that are executed by these programmable stages are called executa- 
bles. All information necessary for defining an executable is encapsulated in a program object. 


If the uniform queried with GetActiveUniform is an array, the uniform name returned will always be the 
name of the uniform array appended with "[0]". 


Shader objects may be attached to program objects before source code has been loaded into the shader 
object, or before the shader object has been compiled. Multiple shader objects of the same type cannot be 
attached to a single program object. However, a single shader object may be attached to more than one 
program object. The error INVALID_OPERATION is generated if shader is already attached to program or if 
multiple shader objects of the same type are being attached to the program. 





There is no default program or shader object in OpenGL ES 2.0. If UseProgram is called with program 
set to 0, then the current program object will refer to an invalid program object. Calls to modify attached 
shaders, compile attached shader objects, attach additional shader objects, and detach shader objects will 
result in an INVALID_VALUE error. DeleteProgram will silently ignore the value zero. 

If the current program object is not a valid program object, then the output of vertex and fragment shader 
as a result of any drawing commands issued using DrawArrays or DrawElements is undefined. 








































































































OpenGL 2.0 Common 
void AttachShader (uint program, uint shader) V 
void BindAttribLocation (uint program, uint index, const J 
char xname) 
void CompileShader (uint shader) t 
uint CreateProgram (void) v 
uint CreateShader (enum type) v 
void DeleteShader (uint shader) JV 
void DetachShader (uint program, uint shader) JV 
void DeleteProgram (uint program) VY 
void GetActiveAttrib (uint program, uint index, sizei 
bufsize, sizei *xlength, int xsize, enum «type, char V 
xname) 
void GetActiveUniform (uint program, uint index, sizei 
bufsize, sizei *xlength, int xsize, enum «type, char V 
xname) 
int GetAttribLocation (uint program, const char *name) V 
void GetShaderiv (uint shader, enum pname, int *params) 
pname = SHADER_TYPE, DELETE_STATUS JV 
pname = COMPILE_STATUS, INFO_LOG_LENGTH t 
pname = SHADER-SOURCE_LENGTH i) 
void GetShaderInfoLog (uint shader, sizei bufsize, sizei 
xlength, char xinfolog) t 
void GetShaderPrecisionFormat (enum shadertype, enum J 
precisiontype, int «range, int *xprecision) 
























































14 OpenGL Operation 
OpenGL 2.0 Common 
void GetShaderSource (uint shader, sizei bufsize, sizei 
xlength, char *«source) I 
int GetUniformLocation (uint program, const char *name) VY 
void LinkProgram (uint program) V 
void ReleaseShaderCompiler() t 
void ShaderBinary (int n, const uint *shaders, enum 
binaryformat, const void «binary, int length) i 
void ShaderSource (uint shader, sizei count, const char 
x*xstring, const int x*length) i 
void Uniform{ 1234} {if} (int location, T value) v 
void Uniform{1234}{if}v (int location, sizei count, T Y 
value) 
void UniformMatrix{234}fv (int location, sizei count, Vt 
boolean transpose, T value) 
void UseProgram (uint program) JV 
void ValidateProgram (uint program) JV 














m OpenGL 2.0 requires a shader compiler and therefore only supports APIs for loading shader 
sources and compiling them. OpenGL ES makes the shader compiler optional and in addition pro- 


vides an optional interface to directly load precompiled shader binaries. 


The transpose parameter in the UniformMatrix API call can only be FALSE in OpenGL ES 2.0. The 
transpose field was added to UniformMatrix as OpenGL 2.0 supports both column major and row 
major matrices. OpenGL ES 1.0 and 1.1 do not support row major matrices because there was 
no real demand for it. There is no reason to support both column major and row major matrices 
in OpenGL ES 2.0, so the default matrix type used in OpenGL (i.e. column major) is the only one 
supported. An INVALID_VALUE error will be generated if tranpose is not FALSE. a 


Chapter 3 


Rasterization 


3.1 Invariance 


The invariance rules are retained in full. 


3.2 Antialiasing 


Multisampling is supported though an implementation is not required to provide a multisample buffer. Mul- 
tisampling can be enabled and/or disabled in OpenGL using the Enable/Disable command. Multisampling 
is only enabled in OpenGL ES 2.0, if the EGLconfig associated with the target render surface uses a multi- 
sample buffer. 





OpenGL 2.0 Common 
void Enable/Disable (MULT ISAMPLE 











~~ 














g Multisampling is a desirable feature. Since an implementation need not provide an actual multi- 
sample buffer and the command overhead is low, it is included. 0 


3.3. Points 


OpenGL ES 2.0 supports aliased point sprites only. The POINT_SPRITE default state is always TRUE. 











OpenGL 2.0 Common 


void PointSize (float size) - 











void PointParameter{if}[v] (enum pname, T param) - 
void Enable/Disable (POINT_SMOOTH) — 
void Enable/Disable (POINT_SPRITE) = 
void Enable/Disable (VERTEX_PROGRAM_POINT_SIZE 
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3.3.1 Point Sprite Rasterization 


Point sprite rasterization produces a fragment for each framebuffer pixel whose center lies inside a square 
centered at the points (xw, yw), with side length equal to the current point sprite. The rasterization rules are 
the same as that defined in the OpenGL 2.0 specification with the following differences: 





e The point sprite coordinate origin is UPPER_-LEFT and cannot be changed. 











e The point size is computed by the vertex shader, so the fixed function to multiply the point size with 
a distance attenuation factor and clamping it to a specified point size range is no longer supported. 


e The point size must be output by a vertex shader when rendering a point primitive. If the point size is 
not output by the vertex shader, the value of point size is undefined 


e Multisample point fade is not supported. 





e The COORD_REPLACE feature where s texture coordinate for a point sprite goes from 0 to 1 across the 
point horizontally left-to-right and ¢ texture coordinate goes from 0 to 1 vertically top-to-bottom is 
replaced by the g1_PointCoord variable defined in the OpenGL ES shading language specification. 
gl_PointCoord becomes available in the fragment shader when rasterizing points and is not related 
to any texture unit. 











m Point sprites are used for rendering particle effects efficiently by drawing them as a point instead of 
a quad. Traditional points (aliased and anti-aliased) have seen very limited use and are therefore no 
longer supported. 0 


3.4 Line Segments 


Aliased lines are supported. Anti-aliased lines and line stippling are not supported. 





OpenGL 2.0 Common 
void LineWidth (float width) JV 
void Enable/Disable (LINE_SMOOTH) = 
void LineStipple (int factor, ushort pattern) - 
void Enable/Disable (LINE_STIPPLE) - 















































3.4.1 Basic Line Segment Rasterization 


All varying attributes must be interpolated with perspective correction. 


3.5 Polygons 


Polygonal geometry support is reduced to triangle strips, triangle fans and independent triangles. All raster- 
ization modes are supported except for point and line PolygonMode and antialiased polygons using polygon 
smooth. Depth offset is supported in FILL mode only. 
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OpenGL 2.0 Common 
void CullFace (enum mode) A 
void Enable/Disable (CULL_FACE) 4 





void PolygonMode (enum face, enum mode) - 
void Enable/Disable (POLYGON_SMOOTH) - 
void PolygonStipple (const ubyte *mask) - 











void GetPolygonStipple (ubyte *«mask) - 
void Enable/Disable (POLYGON_STIPPLE) - 
void PolygonOffset (float factor, float units) V 
void Enable/Disable (enum cap) 
cap = POLYGON_OFFSET_FILL V 
cap = POLYGON_OFFSET_LINE, POLYGON_OFFSET_POINT - 


















































m Support for all triangle types (independents, strips, fans) is not overly burdensome and each type 
has some desirable utility: strips for general performance and applicability, independents for efficiently 
specifying unshared vertex attributes, and fans for representing "corner-turning” geometry. Face 
culling is important for eliminating unnecessary rasterization. Polygon stipple is desirable for doing 
patterned fills for "presentation graphics”. It is also useful for transparency, but support for alpha is 
sufficient for that. Polygon stippling does represent a large burden for the polygon rasterization path 
and can usually be emulated using texture mapping and alpha test, so it is omitted. Polygon offset for 
filled triangles is necessary for rendering coplanar and outline polygons and if not present requires 
either stencil buffers or application tricks. Antialiased polygons using POLYGON_SMOOTH is just as 
desirable as antialiasing for other primitives, but is too large an implementation burden to include. a 


3.5.1 Basic Polygon Rasterization 


All varying attributes must be interpolated with perspective correction. 


3.6 Pixel Rectangles 


No support for directly drawing pixel rectangles is included. Limited PixelStore support is retained to allow 
different pack alignments for ReadPixels and unpack alignments for TexImage2D. DrawPixels, PixelTransfer 
modes and PixelZoom are not supported. The Imaging subset is not supported. 











OpenGL 2.0 Common 
void PixelStorei (enum pname, T param) 
pname = PACK_ALIGNMENT, UNPACK_ALIGNMENT JV 
pname = <all other values> = 


void PixelStoref (enum pname, T param) - 





void PixelTransfer {if} (enum pname, T param) - 





void PixelMap{ui us f}v(enum map, int size, T *values) — 





void GetPixelMap{uiusf}v(enum map, T *values) - 








void Enable/Disable (COLOR_TABLE 
void ColorTable (enum target, enum internalformat, sizei 

















width, enum format, enum type, const void xtable) 
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OpenGL 2.0 


void ColorSubTable (enum target, sizei start, sizei 
count, enum format, enum type, const void xdata) 


Common 





void ColorTableParameter{if}v (enum target, enum pname, T 
xparams) 





void GetColorTableParameter{if}v (enum target, enum pname, T 


xparams) 





void CopyColorTable (enum target, enum internalformat, 
int x, int y, sizei width) 





void CopyColorSubTable (enum target, sizei start, int x, 
int y, sizei width) 





void GetColorTable (enum target, enum format, enum type, 
void xtable) 








void ConvolutionFilter1D (enum target, enum internalformat, 
sizei width, enum format, enum type, const void 


*ximage) 





void ConvolutionFilter2D (enum target, enum internalformat, 
sizei width, sizei height, enum format, enum type, 
const void *image) 





void GetConvolutionFilter (enum target, enum format, enum 
type, void«image) 





void CopyConvolutionFilter1D (enum target, enum 


internalformat, int x, int y, sizei width) 





void CopyConvolutionFilter2D (enum target, enum 





internalformat, int x, int y, sizei width, sizei 
height) 





void SeparableFilter2D (enum target, enum internalformat, 
sizei width, sizei height, enum format, enum type, 


const void x*xrow, const void *column) 





void GetSeparableFilter (enum target, enum format, enum 
type, void *row, void *column, void *span) 





void ConvolutionParameter {if}[v] (enum target, enum pname, T 
param) 





void GetConvolutionParameter{if}v (enum target, enum pname, T 
xparams) 








void Enable/Disable (POST_CONVOLUTION_COLOR_TABLE) 








void MatrixMode (COLOR) 





void Enable/Disable (POST_COLOR_MATRIX_COLOR_TABLI 





Fl 
~~ 











void Enable/Disable (HISTOGRAM) 





void Histogram (enum target, sizei width, enum 
internalformat, boolean sink) 








void ResetHistogram (enum target) 
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OpenGL 2.0 Common 
void GetHistogram (enum target, boolean reset, enum 
format, enum type, void xvalues) 





void GetHistogramParameter {if}v (enum target, enum pname, T 
*params) 








void Enable/Disable (MINMAX) — 
void Minmax (enum target, enum internalformat, boolean 





sink) 





void ResetMinmax (enum target) - 





void GetMinmax (enum target, boolean reset, enum 


format, enum types, void *values) 





void GetMinmaxParameter{if}v (enum target, enum pname, T 
*params) 








void DrawPixels (sizei width, sizei height, enum format, 
enum type, void xdata) 





void PixelZoom (float xfactor, float yfactor) - 














mg The OpenGL 2.0 specification includes substantial support for operating on pixel images. The 
ability to draw pixel images is important, but with the constraint of minimizing the implementation 
burden. There is a concern that DrawPixels is often poorly implemented on hardware accelerators 
and that many applications are better served by emulating DrawPixels functionality by initializing a 
texture image with the host image and then drawing the texture image to a screen-aligned quadrilat- 
eral. This has the advantage of eliminating the DrawPixels processing path and and allows the image 
to be cached and drawn multiple times without re-transferring the image data from the application’s 
address space. However, it requires extra processing by the application and the implementation, 
possibly requiring the image to be copied twice. 

The command PixelStore must be included to allow changing the pack alignment for ReadPixels and 
unpack alignment for TexImage2D to something other than the default value of 4 to support ubyte 
RGB image formats. The integer version of PixelStore is retained rather than the floating-point version 
since all parameters can be fully expressed using integer values. 0 


3.7 Bitmaps 


Bitmap images are not supported. 





OpenGL 2.0 Common 


void Bitmap (sizei width, sizei height, float xorig, 








float yorig, float xmove, float ymove, const ubyte - 











xbitmap) 





g The Bitmap command is useful for representing image data compactly and for positioning images 
directly in window coordinates. Since DrawPixels is not supported, the positioning functionality is not 
required. A strong enough case hasn’t been made for the ability to represent font glyphs or other 
data more efficiently before transfer to the rendering pipeline. a 
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3.8 Texturing 


1D textures, and depth textures are not supported. 2D textures, and cube maps are supported with the 
following exceptions: only a limited number of image format and type combinations are supported, listed 
in Table 3.1. 3D textures are not required but can be optionally supported through the OES _texture_3D 
extension. 

OpenGL 2.0 implements power of two and non-power of two ID, 2D, 3D textures and cube- 
maps. The power and non-power of two textures support all texture wrap modes and can be mip-mapped in 
OpenGL 2.0. 


OpenGL ES 2.0 supports non-power of two 2D textures, and cubemaps, with the caveat that mip- 
mapping and texture wrap modes other than clamp to edge are not supported. Mip-mapping and all OpenGL 
ES 2.0 texture wrap modes are supported for power of two 2D textures, and cubemaps. 

The OES_texture_npot extension allows implementations to support mip-mapping and REPEAT and 
MIRRORED_REPEAT texture wrap modes for non-power of two 2D textures, cubemaps, and also for 3D 
textures, if OES_texture_3D extension is supported. 

Table 3.2 summarizes the disposition of all image types. The only internal formats supported are the 
base internal formats: RGBA, RGB, LUMINANCE, ALPHA, and LUMINANCE_ALPHA. The format must match 
the base internal format (no conversions from one format to another during texture image processing are 
supported) as described in Table 3.1. If the texture format does not match the base internal format an 
INVALID OPERATION error results Texture borders are not supported (the border parameter must be 






































































































































zero, and an INVALID_VALUE error results if it is non-zero). 
Internal Format External Format Type Bytes per Pixel 
RGBA RGBA UNSIGNED_BYTE 4 
RGB RGB UNSIGNED_BYTE 3 
RGBA RGBA UNS IGNED_SHORT_4_4_4_4 2 
RGBA RGBA UNSIGNED_SHORT_5_5_5_1 2 
RGB RGB UNSIGNED_SHORT_5_6_5 2 
LUMINANCE_ALPHA | LUMINANCE_ALPHA | UNSIGNED_BYTE 2 
LUMINANCE LUMINANCE UNSIGNED_BYTE 1 
ALPHA ALPHA UNSIGNED_BYTE 1 












































Table 3.1: Texture Image Formats and Types 


3.8.1 Copy Texture 


CopyTexImage and CopyTexSubImage are supported. The internal format parameter can be any of the base 
internal formats described for TexImage2D subject to the constraint that color buffer components can be 
dropped during the conversion to the base internal format, but new components cannot be added. For exam- 
ple, an RGB color buffer can be used to create LUMINANCE or RGB textures, but not ALPHA, LUMINANCE_- 
ALPHA, or RGBA textures. Table 3.3 summarizes the allowable framebuffer and base internal format combi- 
nations. If the framebuffer format is not compatible with the base texture format an INVALID_OPERATION 
error results. 

An INVALID_FRAMEBUFFER_OPERATION error will be generated if an attempt is made to execute Copy- 
TexImage and CopyTexSubImage, while the object bound to FRAMEBUFFER_BINDING is not framebuffer 
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complete. 
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Table 3 


Table 3.2: Image Types 











Texture Format 





Color Buffer 
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.3: CopyTexture Internal Format/Color Buffer Combinations 
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3.8.2 Compressed Textures 


Compressed textures are supported including sub-image specification; however, no method for reading back 
a compressed texture image is included, so implementation vendors must provide separate tools for creating 
compressed images. The generic compressed internal formats are not supported, so compression of textures 
using TexImage2D, TexImage3D is not supported. 


3.8.3. Texture Wrap Modes 











Wrap modes REPEAT, CLAMP_TO_EDGE and MIRRORED_REPEAT are the only wrap modes supported for 
texture coordinates. The texture parameters to specify the magnification and minification filters are sup- 
ported. Texture priorities, LOD clamps, and explicit base and maximum level specification, auto mipmap 
generation, depth texture and texture comparison modes are not supported. Texture objects are supported, 
but proxy textures are not supported. 
































3.8.4 Texture Minification 


The OpenGL 2.0 texture minification filters are supported by OpenGL ES 2.0. Mip-mapped non-power of 
two textures are optional in OpenGL ES 2.0. If an implementation supports mip-mapped non-power of two 
textures, it will export the OES_texture_npot extension. 





3.8.5 Texture Magnification 
The OpenGL 2.0 texture magnification filters are supported by OpenGL ES 2.0 


3.8.6 Texture Framebuffer Attachment 


The texture values are considered undefined if all of the following conditions are true: 














e The current FRAMEBUFFER_BINDING names an application-created framebuffer object F. 


e The texture is attached to one of the attachment points, A, of framebuffer object F. 











e TEXTURE_MIN_FILTER is NEAREST or LINEAR, and the value of FRAMEBUFFER_ATTACHMENT_- 
EXTURE_LEVEL for attachment point A is equal to the base level -or- TEXTURE_MIN_FILTER is 
NEAREST_MIPMAP_NEAREST, NEAREST_MIPMAP_LINEAR, LINEAR_MIPMAP_NEAREST, or LINEAR_- 
MIPMAP_LINEAR, and the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for attachment 
point A is within the the inclusive range from level 0 to last mip-level. 
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3.8.7 Texture Completeness 


A texture is said to be complete if all the image arrays and texture parameters required to utilize the texture 
for texture application are consistently defined. The definition of completeness varies depending on the 
texture dimensionality. 


For 2D and 3D textures, a texture is complete in OpenGL ES if the following conditions all hold true: 


e the set of mipmap arrays are specified with the same type and the same format. 


e the dimensions of the arrays follow the sequence described in the Mimapping discussion of section 
3.8.8 of the OpenGL 2.0 specification. 
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For cube map textures, a texture is cube complete if the following conditions all hold true: 


e the base level arrays of each of the six texture images making up the cube map have identical, positive, 
and square dimensions. 


e the base level arrays were specified with the same type and the same format. 


Finally, a cube map texture is mipmap cube complete if, in addition to being cube complete, each of the 
six texture images considered individually is complete. 


For non power of two 2D, 3D textures and cubemaps, on implementations that do not support OES_- 
texture_npot extension, a texture is said to be complete if the following additional conditions all hold 
true: 








e the minification filter is NEAREST or LINEAR. 




















e the texture wrap mode is CLAMP_TO_EDGE 








The check for completeness is done when a given texture is used to render geometry. 


3.8.8 Manual Mipmap Generation 


Mipmaps can be generated manually with the command 


void GenerateMipmap(enum target) 




















where target is TEXTURE_2D, or TEXTURE_CUBE_MAP. Mipmap generation affects the texture image 
attached to target. For cube map textures, INVALID_OPERATION is generated if the texture bound to target 
is not cube complete. 

Mipmap generation replaces texture array levels from level one through the last mip-level with arrays 
derived from the base level array. The contents of the derived arrays are computed by repeated, filtered re- 
duction of the base level array. No particular filter algorithm is required, though a box filter is recommended 
as the default filter. In some implementations, filter quality may be affected by hints. 











3.8.9 Texture State 


The state necessary for texture can be divided into two categories. First, there are the seven sets of mipmap 
arrays (one for the two-dimensional texture target and six for the cube map texture targets) and their number. 
Each array has associated with it a width, height (two-dimensional and cubemap only), an integer describing 
the internal format of the image, a boolean describing whether the image is compressed or not, and an integer 
size of a compressed image. 

Each initial texture array is null (zero width, and height, internal format undefined, with the compressed 
flag set to FALSE, a zero compressed size, and zero-sized components). The second type of state is given by 
two sets of texture properties; each consists of the selected minification and magnification filters, the wrap 
modes for s, and t (two-dimensional and cubemap only), and a boolean flag indicating whether the texture 
is resident. The value of the resident flag is determined by OpenGL ES and may change as a result of other 
OpenGL ES operations, and cannot be queried in OpenGL ES 2.0. In the initial state, the value assigned to 
TEXTURE_MIN_FILTER is NEAREST_MIPMAP_LINEAR, and the value for TEXTURE_MAG_FILTER is LINEAR. 
s, and t wrap modes are all set to REPEAT. 
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3.8.10 Texture Environments and Texture Functions 


The OpenGL 2.0 texture environments are no longer supported. The fixed function texture functionality is 


replaced by programmable fragment shaders. 





OpenGL 2.0 

void TexImage1D (enum target, int level, 
width, 
const void xpixels) 


int 


internalFormat, sizei int border, enum 








format, enum type, 


Common 





void TexImage2D (enum target, int level, enum internalFormat, 





































































































sizei height, int border, enum format, enum type, 
target = TEXTURE_2D, border = 0 
target = TEXTURE_CUBE_MAP_POSITIVE_X, border = 0 
target = TEXTURE_CUBE MAP POSITIVE_Y, border = 0 
target = TEXTURE_CUBE_MAP_POSITIVE_Z, border = 0 
target = TEXTURE_CUBE MAP NEGATIVE_X, border = 0 
target = TEXTURE_CUBE_MAP_NEGATIVE_Y, border = 0 
target = TEXTURE_CUBE MAP NEGATIVE_Z, border = 0 
target = PROXY_TEXTURE_2D 
border > 0 





const void x*pixels) 


sizei width, 


Jt 
Ji 
Jt 
ft 
Jt 
Ji 
Ji 





void TexImage3D (enum target, int level, enum internalFormat, 


























sizei width, 
































border > 0 


sizei height, sizei depth, int border, enum format, enum type, const 
void xpixels) 
target = TEXTURE_3D, border = 0 - 
target = PROXY_TEXTURE_3D - 
border > 0 = 
void GetTexImage (enum target, int level, enum format, 
enum type, void xpixels) a 
void TexSubImage1D (enum target, int level, int xoffset, 
sizei width, enum format, enum type, const void = 
xpixels) 
void TexSubImage2D (enum target, int level, int xoffset, 
int yoffset, sizei width, sizei height, enum format, Jt 
enum type, const void xpixels) 
void TexSubImage3D (enum target, int level, int xoffset, 
int yoffset, int zoffset, sizei width, sizei height, 
sizei depth, enum format, enum type, const void ~ 
xpixels) 
void CopyTexImage1D (enum target, int level, enum 
internalformat, int x, int y, sizei width, int _ 
border) 
CopyTexImage2D (enum target, int level, enum internalformat, int x, int y, 
sizei width, sizei height, int border) 
border = 0 me 
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sizei height) 


OpenGL 2.0 Common 
void CopyTexSubImage1D (enum target, int level, int 

xoffset, int x, int y, sizei width) 7 
void CopyTexSubImage2D (enum target, int level, int 

xoffset, int yoffset, int x, int y, sizei width, Jt 





void CopyTexSubImage3D (enum target, int level, int 
xoffset, int yoffset, int zoffset, int x, int y, 





sizei width, sizei height) 





void CompressedTexImage1D (enum target, int level, enum 
internalformat, sizei width, int border, sizei 





imageSize, const void xdata) 

















































































































target = TEXTURE_2D, border = 0 

target = TEXTURE_CUBE_MAP_POSITIVE_X, border = 0 
target = TEXTURE_CUBE-MAP-POSITIVE_Y, border = 0 
target = TEXTURE_CUBE_MAP_POSITIVE_Z, border = 0 
target = TEXTURE_CUBE_MAP_NEGATIVE_X, border = 0 
target = TEXTURE_CUBE_MAP_NEGATIVE_Y, border = 0 
target = TEXTURE_CUBE_MAP_NEGATIVE_Z, border = 0 
target = PROXY_TEXTURE_2D 














border > 0 





CompressedTexImage2D (enum target, int level, enum internalformat, sizei 
width, sizei height, int border, sizei imageSize, const void xdata) 


Jt 
Ji 
Jt 
Ji 
Jt 
Ji 
Jt 





void xdata) 
target = TEXTURE_3D, border = 0 
target = PROXY_TEXTURE_3D 
border > 0 


























void CompressedTexImage3D (enum target, int level, enum internalformat, sizei 
width, sizei height, sizei depth, int border, sizei imageSize, const 





void CompressedTexSubImage1D (enum target, int level, int 
xoffset, sizei width, enum format, sizei imageSize, 
const void xdata) 





void CompressedTexSubImage2D (enum target, int level, int 
xoffset, int yoffset, sizei width, sizei height, 
enum format, sizei imageSize, const void xdata) 


Ji 





void CompressedTexSubImage3D (enum target, int level, int 
xoffset, int yoffset, int zoffset, sizei width, 
sizei height, sizei depth, enum format, sizei 
imageSize, const void xdata) 





void GetCompressedTexImage (enum target, int lod, void 
*img) 





void TexParameter{if}[v] (enum target, enum pname, T param) 
target = EXTURE_2D, TEXTURE_CUBE_MAP 
target = TEXTURE_3D 
target EXTURE_1D 
pname = TEXTURE_MIN_FILTER, TEXTURE_-MAG_FILTER 
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OpenGL 2.0 


pname = 








EXTU 
EXTU 
EXTU 








L E_WRAP_S, TEXTURE_WRAP_T 

a E_WRAP_R 

T EF BORDER-COLOR 

TEXTURE_MIN_LOD, TEXTURE_MAX-_LOD 

TEXTURE_BASE_LEVEL, TEXTURE_MAX_LEVEL 
pname = TEXTURE_LOD_BIAS 

D 

iL 

iL 

T 











pname = 














pname = 











pname = 





























pname = 








DHDWDHD WD DW 




















EPTH_TEXTURE_MODE 
EX TURE_COMPARE_MODE 
EXTURE_COMPARE_FUNC 
pname = TEXTURE_-PRIORITY 

pname = GENERATE_MIPMAP 


pname = 

















pname = 








pname = 












































Common 
V 





void GetTexParameter{if}v (enum target, enum pname, T 


xparams) 





void GetTexLevelParameter{if}v (enum target, int level, enum 
pname, T x*params) 





void BindTexture (enum target, uint texture) 
TEXTURE_2D, TEXTURE_CUBE_MAP 
TEXTURE_3D 

TEXTURE_1D 

















target 





target 

















target 





ww 





void DeleteTextures (sizei n, const uint *xtextures) 





void GenTextures (sizei n, uint xtextures) 





boolean IsTexture (uint texture) 


1% 





boolean AreTexturesResident (sizei n, uint *textures, 
boolean *xresidences) 








void PrioritizeTextures (sizei n, uint x*textures, clampf 


xpriorities) 





void Enable/Disable (enum cap) 
cap = TEXTURE_2D, TEXTURE_CUBE_MAP 
cap = TEXTURE_3D 
cap = TEXTURE_1D, TEXTURE_3D 















































void TexEnv{if}[v] (enum target, enum pname, T param) 





void GetTexEnv{if}v (enum target, enum pname, T *params) 








void GenerateMipmap (enum target) 





V 








m Texturing with 2D images is a critical feature for entertainment, presentation, and engineering 
applications. Cubemaps are also important since they can provide very useful functionality such 
as reflections, per-pixel specular highlights etc. These features can also be implemented using 2D 
textures. However more than 1 texture unit will be needed to do this (eg. dual paraboloid environment 
mapping). Cubemaps allow efficient use of the available texture image units in hardware and are 
therefore added to OpenGL ES 2.0. 3D textures are also very useful for rendering volumetric effects, 
and have been used by quite a few games on the desktop and are therefore optionally supported. 


1D textures are not supported since they can be described as a 2D texture with a height of one. 
Texture objects are required for managing multiple textures. In some applications packing multiple 
textures into a single large texture is necessary for performance, therefore subimage support is also 
included. Copying from the framebuffer is useful for many shading algorithms. A limited set of for- 
mats, types and internal formats is included. The RGB component ordering is always RGB or RGBA 
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rather than BGRA since there is no real perceived advantage to using BGRA. Format conversions 
for copying from the framebuffer are more liberal than for images specified in application memory, 
since an application usually has control over images authored as part of the application, but has little 
control over the framebuffer format. Unsupported CopyTexture conversions generate an INVALID_- 
OPERATION error, since the error is dependent on the presence of a particular color component in 
the colorbuffer. This behavior parallels the error treatment for attempts to read from a non-existent 
depth or stencil buffer. 


Texture borders are not included, since they are often not completely supported by full OpenGL 
implementations. All filter modes are supported since they represent a useful set of quality and speed 
options. Edge clamp and repeat wrap modes are both supported since these are most commonly 
used. Texture priorities are not supported since they are seldom used by applications. Similarly, the 
ability to control the LOD range and the base and maximum mipmap image levels is not included, 
since these features are used by a narrow set of applications. Since all of the supported texture 
parameters are scalar valued, the vector form of the parameter command is eliminated. 

Auto mipmap generation has been removed since we can use the GenerateMipmap call to generate 
the mip-levels of a texture. There is no reason to support two different methods for generating mip- 
levels of a texture. 


Compressed textures are important for reducing space and bandwidth requirements. The OpenGL 
2.0 compression infrastructure is retained. Q 
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3.9 Color Sum 


The Color Sum function is subsumed by the fragment shader, and therefore is not supported. 


3.10 Fog 


The Fog fixed fragment function can be implemented by the fragment shader. Fog is therefore no longer 
supported. 





OpenGL 2.0 Common 


void Fogf[v] (enum pname, T param) - 





void Fogi[v] (enum pname, T param) - 
void Enable/Disable (FOG) - 

















3.11. Fragment Shaders 


OpenGL ES 2.0 supports programmable fragment shader only and replaces the following fixed function 
fragment processing: 


e The texture environments and texture functions are not applied. 
e Texture application is not applied. 
e Color sum is not applied. 


e Fog is not applied. 


A fragment shader is a binary or an array of strings containing source code for the operations that are 
meant to occur on each fragment that results from rasterizing a point, line segment or triangle/strip/fan. The 
language used for fragment shaders is described in the OpenGL ES shading language. 


Chapter 4 


Per-Fragment Operations and the 
Framebuffer 


The framebuffer consists of a set of pixels arranged as a two-dimensional array. The height and width of 
this array may vary from one OpenGL ES implementation to another. For purposes of this discussion, each 
pixel in the framebuffer is simply a set of some number of bits. The number of bits per pixel may also vary 
depending on the particular OpenGL ES implementation or context. 


Further there are two classes of framebuffers: the default framebuffer supplied by the window-system- 
provided and application-created framebuffer objects. Every OpenGL ES context has a single default 
window-system-provided framebuffer. Applications can optionally create additional non-displayable frame- 
buffer objects. (For more information on application-created framebuffer objects see section 4.4) 


Corresponding bits from each pixel in the framebuffer are grouped together into a bitplane; each bitplane 
contains a single bit from each pixel. These bitplanes are grouped into several logical buffers. These are 
the color, depth, and stencil buffers. The color buffer actually consists of a number of buffers, and these 
color buffers serve related but slightly different purposes depending on whether it is bound to the default 
window-system-provided framebuffer or to an application-created framebuffer object. 


For the default window-system-provided framebuffer, the color buffers are: the front buffer, and the 
back buffer. Typically, the contents of the front buffers are displayed on a color monitor or LCD panel while 
the contents of the back buffers are invisible. All color buffers must have the same number of bitplanes. 
Further, an implementation or context may not provide depth, or stencil buffers. 


For application-created framebuffer objects, the color buffers are not visible, and consequently the 
names of the color buffers are not related to a display device. The name of the color buffer of an application- 
created framebuffer object is COLOR_-ATTACHMENTO. The names of the depth and stencil buffers are DEP TH_- 
ATTACHMENT and STENCIL_ATTACHMENT. For more information about the buffers of an application-created 
framebuffer object, see section 4.4.2. To be considered framebuffer complete (see section 4.4.4), all color 
buffers attached to an application-created framebuffer object must have the same number of bitplanes. Depth 
and stencil buffers may optionally be attached to application-created framebuffers as well. 























Color buffers consist of R, G, B, and, optionally, A unsigned integer values. The number of bitplanes 
in each of the color buffers, the depth buffer, and the stencil buffer is dependent on the currently bound 
framebuffer. For the default framebuffer, the number of bitplanes is fixed. For application-created frame- 
buffer objects, however, the number of bitplanes in a given logical buffer may change if the state of the 
corresponding framebuffer attachment or attached image changes. 
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4.1 Per-Fragment Operations 


All OpenGL 2.0 per-fragment operations are supported, except for occlusion queries, logic-ops, alpha test 
and color index related operations. Depth and stencil operations are supported, but a selected config is not 
required to include a depth or stencil buffer with the caveat that an OpenGL ES 2.0 implementation must 
support at least one config with a depth bit depth of 16 or higher and a stencil bit depth of 8 or higher. 


4.1.1 Pixel Ownership Test 


The first test is to determine if the pixel at location (x,,, y~) in the framebuffer is currently owned by this 
OpenGL ES context. If it is not, the window system decides the fate the incoming fragment. Possible results 
are that the fragment is discarded or that some subset of the subsequent per-fragment operations are applied 
to the fragment. This test allows the window system to control the behavior of OpenGL ES, for instance, 
when an OpenGL ES window is obscured. 

While an application-created framebuffer object is bound to FRAMEBUFFER, the pixel ownership test 
always passes. The pixels of application-created frambuffer objects are always owned by OpenGL ES, 
not the window system. Only while the window-system-provided framebuffer named zero is bound to 
FRAMEBUFFER does the window system control pixel ownership. 


























4.1.2 Alpha Test 


Alpha test is not supported since this can be done inside a fragment shader. 


4.1.3 Stencil Test 


StencilFuncSeparate and StencilOpSeparate take a face argument which can be FRONT, BACK or FRONT_- 
AND_BACK and indicates which set of state is affected. StencilFunc and StencilOp set front and back stencil 
state to identical values. 

StencilFunc and StencilFuncSeparate take three arguments that control where the stencil test passes or 
fails. ref'is an integer reference value that is used in the unsigned stencil comparison. func is a symbolic con- 
stant that determines the stencil comparison function; the eight symbolic constants are NEVER, ALWAYS, 
LESS, LEQUAL, EQUAL, GEQUAL, GREATER, or NOTEQUAL. 

StencilOp and StencilOpSeparate take three arguments that indicate what happens to the stored stencil 
value if this or certain subsequent tests fail or pass. sfails indicates what action is taken if the stencil test 
fails. The symbolic constants are KEEP, ZERO, REPLACE, INCR, DECR, INVERT, INCR_WRAP and 
DECR_WRAP. These correspond to keeping the current value, setting to zero, replacing with the refer- 
ence value, incrementing with saturation, decrementing with saturation, bit-wise inverting it, incrementing 
without saturation, and decrementing without saturation. 


4.1.4 Blending 


Blending works as defined in the OpenGL 2.0 specification. The only difference is that BlendEquation 
and BlendEquationSeparate only support the FUNC_ADD, FUNC_SUBTRACT and FUNC_REVERSE_SUBTRACT 
modes for RGB and alpha. 




















OpenGL 2.0 Common 
void Enable/Disable (SCISSOR_TEST) VY 
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OpenGL 2.0 Common 
void Scissor (int x, int y, sizei width, sizei height) A 
void Enable/Disable (SAMP LE_COVERAGE) V 
void Enable/Disable (SAMP LE_ALPHA_TO_COVERAGE) V 
void Enable/Disable (SAMP LE_ALPHA_TO_ONE) - 
void SampleCoverage (clampf value, boolean invert) V 








void Enable/Disable (ALPHA_TEST) - 
void AlphaFunc (enum func, clampf ref) - 

















void Enable/Disable (STENCIL_TEST) 
void StencilFunc (enum func, int ref, uint mask) 

















void StencilFuncSeparate (enum face, enum func, int ref, 
uint mask) 





void StencilOp (enum fail, enum zfail, enum zpass) 





void StencilOpSeparate (enum face, enum fail, enum zfail, 


Sb SR 


enum zpass) 











void Enable/Disable (DEP TH_TEST) 
void DepthFunc (enum func) 











<]< 











void Enable/Disable (BLEND) Vv 
void BlendFunc (enum sfactor, enum dfactor) V4 
VY 








void BlendFuncSeparate (enum srcRGB, enum dstRGB, enum 
srcAlpha, enum dstAlpha) 





void BlendEquation (enum mode) Vii 





void BlendEquationSeparate (enum modeRGB, enum modeAlpha) Vi 





void BlendColor (clampf red, clampf green, clampf blue, 
clampf alpha) 








void Enable/Disable (D I THER) VY 














void Enable/Disable (INDEX_LOGIC_OP) —- 














void Enable/Disable (COLOR_-LOGIC_OP ) - 
void LogicOp (enum opcode) - 











void BeginQuery (enum target, uint id) — 





void EndQuery (enum target) — 





void GenQueries (sizei n, uint xids) — 

















void DeleteQueries (sizei n, uint xids) — 





@ Scissor is useful for providing complete control over where pixels are drawn and some form of 
window/drawing-surface scissoring is typically present in most rasterizers so the cost is small. Alpha 
testing can be implemented in the fragment shader, therefore the API calls to do the fixed function 
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alpha test are removed. Stenciling is useful for drawing with masks and for a number of presentation 
effects. Depth buffering is essential for many 3D applications and the specification should require 
some form of depth buffer to be present. Blending is necessary for implementing transparency, 
color sums, and some other useful rendering effects. Dithering is useful on displays with low color 
resolution, and the inclusion doesn’t require dithering to be implemented in the renderer. Masked 
operations are supported since they are often used in more complex operations and are needed to 
achieve invariance. 0 


4.2 Whole Framebuffer Operations 


All whole framebuffer operations are supported except for color index related operations, drawing to differ- 
ent color buffers, and accumulation buffer. 





OpenGL 2.0 Common 


void DrawBuffer (enum mode) - 





void IndexMask (uint mask) = 





void ColorMask (boolean red, boolean green, boolean 
blue, boolean alpha) 

void Clear (bitfield mask) 

void ClearColor (clampf red, clampf green, clampf blue, 








Rh 


clampf alpha) 

void ClearIndex (float c) 

void DepthMask (boolean flag) 
void ClearDepth (clampd depth) 
void ClearDepthf (clampf depth) 
void StencilMask (uint mask) 








<] | 














void StencilIMaskSeparate (enum face, uint mask) 





<I) 


void ClearStencil (int s) 








void ClearAccum (float red, float green, float blue, 
float alpha) 
void Accum(enum op, float value) — 

















m= Multiple drawing buffers are not exposed; an application can only draw to the default buffer, so 
DrawBuffer is not necessary. The accumulation buffer is not used in many applications, though it is 
useful as a non-interactive antialiasing technique. O 


4.3. Drawing, Reading, and Copying Pixels 


ReadPixels is supported with the following exceptions: the depth and stencil buffers cannot be read from and 
the number of format and type combinations for ReadPixels is severely restricted. Two format/type combi- 
nations are supported: format RGBA and type UNSIGNED_BYTE for portability; and one implementation- 
specific preferred format/type combination queried using the tokens IMPLEMENTATION_COLOR_-READ_- 
FORMAT and IMPLEMENTATION_COLOR_READ_TYPE. The preferred format/type combination queried may 
depend on the read surface bound to the current OpenGL ES context. If FRAMEBUFFER_BINDING is non- 
zero, the pixel values are read from the buffer attached as the COLOR_-ATTACHMENTO attachment to the 
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currently bound framebuffer object. CopyPixels and ReadBuffer are not supported. Read operations return 
data from the default color buffer. 





OpenGL 2.0 Common 
void ReadBuffer (enum mode) = 





void ReadPixels (int x, int y,sizei width, sizei height, Jt 


enum format, enum type, void *pixels) 





void CopyPixels (int x, int y, sizei width, sizei height, 
enum type) 














mg Reading the color buffer is useful for some applications and also provides a platform independent 
method for testing. Pixel copies can be implemented by reading to the host and then drawing to the 
color buffer (using texture mapping for the drawing part). Image copy performance is important to 
many presentation applications, so CopyPixels may be revisited in a future revision. Drawing to and 
reading from the depth and stencil buffers is not used frequently in applications (though it would be 
convenient for testing), so it is not included. ReadBuffer is not required since the concept of multiple 
drawing buffers is not exposed. 0 


4.4 Framebuffer Objects 


As described in chapters 1 and 2, OpenGL ES renders into (and reads values from) a framebuffer. OpenGL 
ES defines two classes of framebuffers: window-system-provided framebuffers and application-created 
framebuffers. 

By default, OpenGL ES uses the window-system-provided framebuffer. The storage, dimensions, 
allocation, and format of the images attached to this framebuffer are managed entirely by the window- 
system. Consequently, the state of the window-system-provided framebuffer, including its images, can 
not be changed by OpenGL ES, nor can the window-system-provided framebuffer itself, or its images, be 
deleted by OpenGL ES. 

The routines described in the following sections, however, can be used to create, destroy, and modify 
the state and attachments of application-created framebuffer objects. 

Application-created framebuffer objects encapsulate the state of a framebuffer in a similar manner to 
the way texture objects encapsulate the state of a texture. In particular, a framebuffer object encapsulates 
state necessary to describe a collection of color, depth, and stencil logical buffers. For each logical buffer, a 
framebuffer-attachable image can be attached to the framebuffer to store the rendered output for that logical 
buffer. Examples of framebuffer-attachable images include texture images and renderbuffer images. 

By allowing the images of a renderbuffer to be attached to a framebuffer, OpenGL ES provides a mech- 
anism to support off-screen rendering. Further, by allowing the images of a texture to be attached to a 
framebuffer, OpenGL ES provides a mechanism to support render to texture. 


4.4.1 Binding and Managing Framebuffer Objects 


The operations described in chapter 4 affect the images attached to the framebuffer object bound to the target 
FRAMEBUFFER. By default, framebuffer bound to the target FRAMEBUFFER is zero, specifying the default 
implementation-dependent framebuffer provided by the windowing system. When the framebuffer bound 
to target FRAMEBUFFER is not zero, but instead names an application-created framebuffer object, then the 
operations described in chapter 4 affect the application-created framebuffer object rather than the default 
framebuffer. 
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The namespace for framebuffer objects is the unsigned integers, with zero reserved by OpenGL ES to 
refer to the default framebuffer. A framebuffer object is created by binding an unused name to the target 
FRAMEBUFFER. The binding is effected by calling 














void BindFramebuffer(enum target, uint framebuffer); 





with target set to FRAMEBUFFER and framebuffer set to the unused name. The resulting framebuffer 
object is a new state vector and has one color attachment point, plus one each for the depth and stencil 
attachment points. 

BindFramebuffer may also be used to bind an existing framebuffer object to target. If the bind is 
successful no change is made to the state of the bound framebuffer object and any previous binding to target 
is broken. The current FRAMEBUFFER binding can be queried using GetIntegerv(F RAMEBUFFER_BINDING). 

While a framebuffer object is bound to the target FRAMEBUFFER, OpenGL ES operations on the target 
to which it is bound affect the images attached to the bound framebuffer object, and queries of the target to 
which it is bound return state from the bound object. In particular, queries of the values specified in table 
6.30 (Implementation Dependent Pixel Depths) are derived from the currently bound framebuffer object. 
The framebuffer object bound to the target FRAMEBUFFER is used as the destination of fragment operations 
and as the source of pixel reads such as ReadPixels. 

In the initial state, the reserved name zero is bound to the target FRAMEBUFFER. There is no application 
created framebuffer object corresponding to the name zero. Instead, the name zero refers to the window 
system provided framebuffer. All queries and operations on the framebuffer while the name zero is bound 
to the target FRAMEBUFFER operate on this default framebuffer. On some implementations, the properties of 
the default window system provided framebuffer can change over time (e.g., in response to window system 
events such as attaching the context to a new window system drawable.) 

Application created framebuffer objects (i.e., those with a non-zero name) differ from the default win- 
dow system provided framebuffer in a few important ways. First and foremost, unlike the window system 
provided framebuffer, application created framebuffers have modifiable attachment points for each logical 
buffer in the framebuffer. Framebuffer attachable images can be attached to and detached from these at- 
tachment points. Also, the size and format of the images attached to application created framebuffers are 
controlled entirely within the OpenGL ES interface, and are not affected by window-system events, such as 
pixel format selection, window resizes, and display mode changes. 

Additionally, when rendering to or reading from an application created framebuffer object, 



















































































e The pixel ownership test always succeeds. In other words, application-created framebuffer objects 
own all of their pixels. 


e There are no visible color buffer bitplanes. This means there is no color buffer corresponding to the 
back, or front color bitplanes. 


e The only color buffer bitplanes are the ones defined by the framebuffer attachment point named 
COLOR_ATTACHMENTO. 








e The only depth buffer bitplanes are the ones defined by the framebuffer attachment point DEPTH_- 
ATTACHMENT. 











e The only stencil buffer bitplanes are the ones defined by the framebuffer attachment point STENCIL_- 
ATTACHMENT. 
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e There is no multisample buffer so the value of the implementation-dependent state variables SAMPLES 
and SAMPLE_BUFFERS are both 0 














Framebuffer objects are deleted by calling 


void DeleteFramebuffers(sizei n, uint *framebuffers); 


framebuffers contains n names of framebuffer objects to be deleted. After a framebuffer object is 
deleted, it has no attachments, and its name is again unused. If a framebuffer that is currently bound to 
the target FRAMEBUFFER Is deleted, it is as though BindFramebuffer had been executed with the target of 
FRAMEBUFFER and framebuffer of zero. Unused names in framebuffers are silently ignored, as is the value 
Zero. 


























The command 


void GenFramebuffers(sizei n, uint *framebuffers); 


returns 7 previously unused framebuffer object names in framebuffers. These names are marked as used, 
for the purposes of GenFramebuffers only, but they acquire state and type only when they are first bound, 
just as if they were unused. 


4.4.2 Attaching Images to Framebuffer Objects 


Framebuffer-attachable images may be attached to, and detached from, application-created framebuffer 
objects. In contrast, the image attachments of the window-system-provided framebuffer may not be changed 
by OpenGL ES. 

A single framebuffer-attachable image may be attached to multiple application-created framebuffer ob- 
jects, potentially avoiding some data copies, and possibly decreasing memory consumption. 

For each logical buffer, the framebuffer object stores a set of state which defines the logical buffer’s 
attachment point. The attachment point state contains enough information to identify the single image 
attached to the attachment point, or to indicate that no image is attached. The per-logical buffer attachment 
point state is listed in table 6.33 

There are two types of framebuffer-attachable images: the image of a renderbuffer object, and an image 
of a texture object. 


4.4.3 Renderbuffer Objects 


A renderbuffer is a data storage object containing a single image of a renderable internal format. OpenGL 
ES provides the methods described below to allocate and delete a renderbuffer’s image, and to attach a 
renderbuffer’s image to a framebuffer object. 

The name space for renderbuffer objects is the unsigned integers, with zero reserved for OpenGL ES. 
A renderbuffer object is created by binding an unused name to RENDERBUFFER. The binding is effected by 
calling 

















void BindRenderbuffer( enum target, uint renderbuffer ); 
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with target set to RENDERBUFFER and renderbuffer set to the unused name. If renderbuffer is not zero, 
then the resulting renderbuffer object is a new state vector, initialized with a zero-sized memory buffer, and 
comprising the state values listed in table 6.32. Any previous binding to target is broken. 

BindRenderbuffer may also be used to bind an existing renderbuffer object. If the bind is successful, no 
change is made to the state of the newly bound renderbuffer object, and any previous binding to target is 
broken. 

While a renderbuffer object is bound, OpenGL ES operations on the target to which it is bound affect 
the bound renderbuffer object, and queries of the target to which a renderbuffer object is bound return state 
from the bound object. 

The name zero is reserved. A renderbuffer object cannot be created with the name zero. If renderbuffer 
is zero, then any previous binding to target is broken and the target binding is restored to the initial state. 

In the initial state, the reserved name zero is bound to RENDERBUFFER. There is no renderbuffer object 
corresponding to the name zero, so client attempts to modify or query renderbuffer state for the target 
RENDERBUFFER while zero is bound will generate errors. 

Using GetIntegerv, the current RENDERBUFFER binding can be queried as RENDERBUFFER BINDING. 

Renderbuffer objects are deleted by calling 










































































void DeleteRenderbuffers( sizei n, const uint *renderbuffers ); 


where renderbuffers contains n names of renderbuffer objects to be deleted. After a renderbuffer 
object is deleted, it has no contents, and its name is again unused. If a renderbuffer that is currently 
bound to RENDERBUFFER is deleted, it is as though BindRenderbuffer had been executed with the target 
RENDERBUFFER and name of zero. Additionally, special care must be taken when deleting a renderbuffer if 
the image of the renderbuffer is attached to a framebuffer object. Unused names in renderbuffers are silently 
ignored, as is the value zero. 

The command 
































void GenRenderbuffers( sizei n, uint *renderbuffers ); 


returns n previously unused renderbuffer object names in renderbuffers. These names are marked as 
used, for the purposes of GenRenderbuffers only, but they acquire renderbuffer state only when they are first 
bound, just as if they were unused. 

The command 


void RenderbufferStorage(enum target, enum internalformat, sizei width, sizei height); 


establishes the data storage, format, and dimensions of a renderbuffer object’s image. target must be 
RENDERBUFFER. internalformat must be color-renderable, depth-renderable, or stencil-renderable. width 
and height are the dimensions in pixels of the renderbuffer. If either width or height is greater than MAX_- 
RENDERBUFFER_SIZE, the the error INVALID_VALUE is generated. If OpenGL ES is unable to create a 
data store of the requested size, the error OUT_OF_MEMORY is generated. RenderbufferStorage deletes any 
existing data store for the renderbuffer and the contents of the data store after calling RenderbufferStorage 
are undefined. 

An OpenGL ES implementation may vary its allocation of internal component resolution based on any 
RenderbufferStorage parameter (except target), but the allocation and chosen internal format must not be a 
function of any other state and cannot be changed once they are established. The actual resolution in bits of 
each component of the allocated image can be queried with GetRenderbufferParameteriv. 
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Attaching Renderbuffer Images to a Framebuffer 


A renderbuffer can be attached as one of the logical buffers of the currently bound framebuffer object by 
calling 


void FramebufferRenderbuffer(enum target, enum attachment, enum renderbuffertarget, uint 
renderbuffer); 





target must be FRAMEBUFFER. An INVALID_OPERATION error is generated if the current value of 
FRAMEBUFFER-_BINDING is zero when FramebufferRenderbuffer is called. attachment should be set to 
one of the attachment points COLOR_ATTACHMENTO, DEPTH_ATTACHMENT or STENCIL_ATTACHMENT. ren- 
derbuffertarget must be RENDERBUFFER and renderbuffer should be set to the name of the renderbuffer 
object to be attached to the framebuffer. renderbuffer must be either zero or the name of an existing ren- 
derbuffer object of type renderbuffertarget, otherwise INVALID_OPERATION is generated. If renderbuffer 
is zero, then the value of renderbuffertarget is ignored. 

If renderbuffer is not zero and if FramebufferRenderbuffer is successful, then the renderbuffer named 
renderbuffer will be used as the logical buffer identified by attachment of the framebuffer currently bound 
to target. The value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for the specified attachment point is 
set to RENDERBUFFER and the value of FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is set to renderbuffer. 
All other state values of the attachment point specified by attachment are set to their default values listed 
in table 6.33. No change is made to the state of the renderbuffer object and any previous attachment to the 
attachment logical buffer of the framebuffer object bound to framebuffer target is broken. If, on the other 
hand, the attachment is not successful, then no change is made to the state of either the renderbuffer object 
or the framebuffer object. 

Calling FramebufferRenderbuffer with the renderbuffer name zero will detach the image, if any, iden- 
tified by attachment, in the framebuffer currently bound to target. All state values of the attachment point 
specified by attachment in the object bound to target are set to their default values listed in table 6.33. 

If arenderbuffer object is deleted while its image is attached to one or more attachment points in the cur- 
rently bound framebuffer, then it is as if FramebufferRenderbuffer had been called, with a renderbuffer of 
0, for each attachment point to which this image was attached in the currently bound framebuffer. In other 
words, this renderbuffer image is first detached from all attachment points in the currently bound frame- 
buffer. Note that the renderbuffer image is specifically not detached from any non-bound framebuffers. 
Detaching the image from any non-bound framebuffers is the responsibility of the application. 
































































































































Attaching Texture Images to a Framebuffer 


OpenGL ES supports copying the rendered contents of the framebuffer into the images of a texture object 
through the use of the routines CopyTexImage2D, and CopyTexSubImage2D. Additionally, OpenGL ES 
supports rendering directly into the images of a texture object. 

To render directly into a texture image, a specified image from a texture object can be attached as one 
of the logical buffers of the currently bound framebuffer object by calling one of the following routines, 
depending on the type of the texture: 


void FramebufferTexture2D(enum target, enum attachment, enum textarget, uint texture, int level); 





The target must be FRAMEBUFFER. An INVALID_OPERATION is generated if the current value of 
FRAMEBUFFER_ BINDING is zero when FramebufferTexture2D is called. attachment must be one of the 
attachment points of the framebuffer. 
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If texture is zero, then textarget, and level are ignored. If texture is not zero, then texture must either 
name an existing texture object with an target of textarget, or texture must name an existing cube map tex- 
ture and textarget must be one of: TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP POSITIVELY, 
TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP NEGATIVE_X, TEXTURE_CUBE MAP NEGATIVE _- 
Y, Of TEXTURE_CUBE_MAP_NEGATIVE_Z. Otherwise, INVALID_OPERATION is generated. 

level specifies the mipmap level of the texture image to be attached to the framebuffer and must be 0. 
Otherwise, INVALID_VALUE is generated. 

For FramebufferTexture2D, if texture is not zero, then textarget must be one of: TEXTURE_2D, TEXTURE_- 
CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP POSITIVE_Y, TEXTURE_CUBE MAP POSITIVE_Z, TEXTURE_ 
CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z. 

If texture is not zero, and if FramebufferTexture2D is successful, then the specified texture image will 
be used as the logical buffer identified by attachment of the framebuffer currently bound to target. The 
value of FRAMEBUFFER ATTACHMENT _OBJECT_TYPE for the specified attachment point is set to TEXTURE 
and the value of FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is set to texture. Additionally, the value of 
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for the named attachment point is set to /evel. If texture is 
a cubemap texture then, the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE the named 
attachment point is set to textarget. All other state values of the attachment point specified by attachment 
are set to their default values listed in table 6.33. No change is made to the state of the texture object, and 
any previous attachment to the attachment logical buffer of the framebuffer object bound to framebuffer 
target is broken. If, on the other hand, the attachment is not successful, then no change is made to the state 
of either the texture object or the framebuffer object. 

Calling FramebufferTexture2D with texture name zero will detach the image identified by attachment, 
if any, in the framebuffer currently bound to target. All state values of the attachment point specified by 
attachment are set to their default values listed in table 6.33. 

If a texture object is deleted while its image is attached to one or more attachment points in the currently 
bound framebuffer, then it is as if FramebufferTexture2D had been called, with a texture of 0, for each 
attachment point to which this image was attached in the currently bound framebuffer. In other words, this 
texture image is first detached from all attachment points in the currently bound framebuffer. Note that the 
texture image is specifically not detached from any other framebuffer objects. Detaching the texture image 
from any other framebuffer objects is the responsibility of the application. 
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4.4.4 Rendering When an Image of a Bound Texture Object is Also Attached to the Frame- 
buffer 


Special precautions need to be taken to avoid attaching a texture image to the currently bound framebuffer 
while the texture object is currently bound and enabled for texturing. Doing so could lead to the creation 
of a ’feedback loop” between the writing of pixels by the OpenGL ES’s rendering operations and the 
simultaneous reading of those same pixels when used as texels in the currently bound texture. In this 
scenario, the framebuffer will be considered framebuffer complete, but the values of fragments rendered 
while in this state will be undefined. The values of texture samples may be undefined as well. 

Specifically, the values of rendered fragments are undefined if all of the following conditions are true: 


e an image from texture object T is attached to the currently bound framebuffer at attachment point A, 
and 


e the texture object T is currently bound to a texture unit U, and 
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e the current programmable vertex and/or fragment processing state makes it possible to sample from 
the texture object T bound to texture unit U 


while either of the following conditions are true: 
































e the value of TEXTURE _MIN_FILTER for texture object T is NEAREST or LINEAR, and the value of 
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for attachment point A is the base level for the texture 
object T, or 









































e the value of TEXTURE_MIN_FILTER for texture object T is one of NEAREST MIPMAP_NEAREST, 
NEAREST_MIPMAP_LINEAR, LINEAR MIPMAP_NEAREST, or LINEAR MIPMAP_LINEAR, and the value 
of FRAMEBUFFER ATTACHMENT_TEXTURE_LEVEL for attachment point A is within the the range of 
mip levels specified, for the texture object T. 








































































































We consider it possible to sample from the texture object T bound to texture unit U if the active fragment 
or vertex shader contains any instructions that might sample from the texture object T bound to U if even 
those instructions might only be executed conditionally. 


4.4.5 Framebuffer Completeness 


A framebuffer object is said to be framebuffer complete if all of its attached images, and all framebuffer 
parameters required to utilize the framebuffer for rendering and reading, are consistently defined and meet 
the requirements defined below. The rules of framebuffer completeness are dependent on the properties of 
the attached images, and on certain implementation-dependent restrictions. A framebuffer must be complete 
to effectively be used as the destination for OpenGL ES framebuffer rendering operations and the source 
for OpenGL ES framebuffer read operations. 

The internal formats of the attached images can affect the completeness of the framebuffer, so it is useful 
to first define the relationship between the internal format of an image and the attachment points to which it 
can be attached. 


e The following internal formats are color-renderable: RGB565, RGBA4, and RGB5_A1. No other for- 
mats, including compressed internal formats, are color-renderable. 


e An internal format is depth-renderable if it is one of the sized internal formats that has a depth- 
renderable internal format value of DEPTH-COMPONENT16. No other formats are depth-renderable. 








e An internal format is stencil-renderable if it is one of the sized internal formats that has a stencil- 
renderable internal format value of STENCIL_INDEX8. No other formats are stencil-renderable. 











Framebuffer Attachment Completeness 





If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for the framebuffer attachment point attachment 
is not NONE, then it is said that a framebuffer-attachable image, named image, is attached to the framebuffer 
at the attachment point. image is identified by the state in attachment as described in section 4.4.2. 

The framebuffer attachment point attachment is said to be framebuffer attachment complete if the value 
of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for attachment is NONE (i.e., no image is attached), or if all 
of the following conditions are true: 






























































© image is acomponent of an existing object with the name specified by FRAMEBUFFER_ATTACHMENT_- 
OBJECT_NAME, and of the type specified by FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE. 
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e The width and height of image must be non-zero. 





e If attachment is COLOR_ ATTACHMENT, then image must have a color-renderable internal format. 

















e If attachment is DEPTH_ATTACHMENT, then image must have a depth-renderable internal format. 


e If attachment is STENCIL_ATTACHMENT, then image must have a stencil-renderable internal format. 








Framebuffer Completeness 


In this subsection, each rule is followed by an error enum in bold. 
The framebuffer object target is said to be framebuffer complete if it is the window-system-provided 
framebuffer, or if all the following conditons are true: 


e All framebuffer attachment points are framebuffer attachment complete. FRAMEBUFFER_INCOM- 
PLETE ATTACHMENT 


e There is at least one image attached to the framebuffer. FRAMEBUFFER INCOMPLETE _MISS- 
ING_ATTACHMENT 


e All attached images have the same width and height. FRAMEBUFFER INCOMPLETE DIMEN- 
SIONS 


e The combination of internal formats of the attached images does not violate an implementation- 
dependent set of restrictions. FRAMEBUFFER_UNSUPPORTED 


The enums in bold after each clause of the framebuffer completeness rules specifies the return value of 
CheckFramebufferStatus that is generated when that clause is violated. If more than one clause is violated, 
it is implementation-dependent as to exactly which enum will be returned by CheckFramebufferStatus. 

Performing any of the following actions may change whether the framebuffer is considered complete or 
incomplete. 


e Binding to a different framebuffer with BindFramebuffer. 


e Attaching an image to the framebuffer with FramebufferTexture2D or FramebufferRenderbuffer. 


Detaching an image from the framebuffer with FramebufferTexture2D or FramebufferRenderbuffer. 


e Changing the width, height, or internal format of a texture image that is attached to the framebuffer 
by calling TexImage2D, CopyTexImage2D and CompressedTexImage2D. 


e Changing the width, height, or internal format of a renderbuffer that is attached to the framebuffer by 
calling RenderbufferStorage. 


Deleting, with DeleteTextures or DeleteRenderbuffers, an object containing an image that is attached 
to a framebuffer object that is bound to the framebuffer. 


Although OpenGL ES defines a wide variety of internal formats for framebuffer-attachable images, such 
as texture images and renderbuffer images, some implementations may not support rendering to particular 
combinations of internal formats. If the combination of formats of the images attached to a framebuffer 
object are not supported by the implementation, then the framebuffer is not complete under the clause 
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labeled FRAMEBUFFER_UNSUPPORTED. There must exist, however, at least one combination of internal 
formats for which the framebuffer cannot be FRAMEBUFFER_UNSUPPORTED. 

Because of the implementation-dependent clause of the framebuffer completeness test in particular, and 
because framebuffer completeness can change when the set of attached images is modified, it is strongly 
advised, though is not required, that an application check to see if the framebuffer is complete prior to 
rendering. The status of the framebuffer object currently bound to target can be queried by calling 

















enum CheckFramebufferStatus(enum target); 





If target is not FRAMEBUFFER, INVALID_ENUM is generated. If CheckFramebufferStatus generates an 
error, 0 is returned. 

Otherwise, an enum is returned that identifies whether or not the framebuffer bound to target is com- 
plete, and if not complete the enum identifies one of the rules of framebuffer completeness that is violated. 
If the framebuffer is complete, then FRAMEBUFFER_COMPLETE is returned. 






































Effects of Framebuffer Completeness on Framebuffer Operations 


If the currently bound framebuffer is not framebuffer complete, then it is an error to attempt to use the 
framebuffer for writing or reading. This means that rendering commands such as DrawArrays, DrawEle- 
ments, any command that reads the framebuffer such as ReadPixels and CopyTexSubImage will generate the 
error INVALID_FRAMEBUFFER_ OPERATION if called while the framebuffer is not framebuffer complete. 

















4.4.6 Effects of Framebuffer State on Framebuffer Dependent Values 


The values of the state variables listed in table 6.30 (Implementation Dependant Pixel Depths) may change 
when a change is made to FRAMEBUFFER_BINDING, to the state of the currently bound framebuffer object, 
or to an image attached to the currently bound framebuffer object. 

When FRAMEBUFFER_BINDING is zero, the values of the state variables listed in table 6.30 are imple- 
mentation defined. 

When FRAMEBUFFER_BINDING is non-zero, if the currently bound framebuffer object is not framebuffer 
complete, then the values of the state variables listed in table 6.30 are undefined. 

When FRAMEBUFFER_BINDING is non-zero and the currently bound framebuffer object is framebuffer 





















































complete, then the values of the state variables listed in table 6.30 are completely determined by FRAMEBUFFE 











BINDING, the state of the currently bound framebuffer object, and the state of the images attached to the 
currently bound framebuffer object. 


4.4.7 Mapping between Pixel and Element in Attached Image 





When FRAMEBUFFER_BINDING is non-zero, an operation that writes to the framebuffer modifies the image 
attached to the selected logical buffer, and an operation that reads from the framebuffer reads from the image 
attached to the selected logical buffer. 

If the attached image is a renderbuffer image, then the window coordinates (x,,, y) corresponds to the 
value in the renderbuffer image at the same coordinates. 

If the attached image is a texture image, then the window coordinates (x,,, y,,) correspond to the value 
in the texture base level image at the same coordinates. 











42 Per-Fragment Operations and the Framebuffer 





Conversion to Framebuffer-Attachable Image Components 











When an enabled color value is written to the framebuffer while FRAMEBUFFER_BINDING is non-zero, for 
each draw buffer the R, G, B, and A values are converted to internal components corresponding to the 
internal format of the framebuffer-attachable image attached to the selected logical buffer, and the resulting 
internal components are written to the image attached to logical buffer. The masking operations described 
by ColorMask, DepthMask and StencilMask, StencilMaskSeparate are also effective. 


4.4.8 Errors 





The error INVALID_FRAMEBUFFER_OPERATION is generated if the value returned by CheckFramebuffer- 
Status is not FRAMEBUFFER_COMPLETE, and any attempts to render to or read from the framebuffer are 
made. 



































The error INVALID_OPERATION is generated if GetFramebufferA ttachmentParameteriv is called while 
the value of FRAMEBUFFER_BINDING is zero. 




















The error INVALID_OPERATION is generated if FramebufferRenderbuffer or FramebufferTexture2D is 
called while the value of FRAMEBUFFER_BINDING is zero. 
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The error INVALID_VALUE is generated if RenderbufferStorage is called with a width or height that is 
greater than MAX_RENDERBUFFER_SIZ! 
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The error INVALID_ENUM is generated if RenderbufferStorage is called with an internalformat that is 
not among of the list of supported color, depth or stencil formats. 











The error INVALID_OPERATION is generated if FramebufferRenderbuffer is called and renderbuffer is 
not the name of a renderbuffer object. 











The error INVALID_OPERATION is generated if FramebufferTexture2D is called and texture is not the 
name of a texture object. 
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The error INVALID_VALUE is generated if FramebufferTexture2D is called with a /evel that is less than 
Zero. 





I 


The error INVALID_VALUI 
than 0. 


The error INVALID_VALUI 
than 0. 





is generated if FramebufferTexture2D is called with a level that is greater 
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is generated if FramebufferTexture2D is called with a level that is greater 

















The error INVALID_ENUM is generated if CheckFramebufferStatus is called and target is not FRAMEBUFFER. 





The error OUT_OF_ MEMORY is generated if OpenGL ES is unable to create a data store of the required 
size when calling RenderbufferStorage. 

















The error INVALID_OPERATION is generated if GenerateMipmap is called with a target of TEXTURE_- 
CUBE_MAP and the texture object currently bound to TEXTURE_CUBE_MAP is not cube complete. 
































OpenGL 2.0 Common 
void BindRenderbuffer (enum target, uint renderbuffer) JV 
void DeleteRenderbuffers (sizei n, const uint / 
xrenderbuffers) 

void GenRenderbuffers (sizei n, uint xrenderbuffers) 4 
void RenderbufferStorage (enum target, enum internalformat, / 











sizei width, sizei height) 
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OpenGL 2.0 


void BindFramebuffer (enum target, uint framebuffer) 


Common 





void DeleteFramebuffers (sizei n, const uint *«framebuffers) 





void GenFramebuffers (sizei n, uint «framebuffers) 





enum CheckFramebufferStatus (enum target) 





void FramebufferTexture2D (enum target, enum attachment, 





num textarget, uint texture, int level) 


<1STSISTS 








void FramebufferRenderbuffer (enum target, enum attachment, 





enum renderbuffertarget, uint renderbuffer) 
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Chapter 5 


Special Functions 


5.1 Evaluators 


Evaluators are not supported. 





OpenGL 2.0 Common 
void Mapl{fd} (enum target, T ul, T u2, int stride, int 
order, T points) 
void Map2{fd} (enum target, T ul, T u2, int ustride, int 
uorder, T vl, T v2, int vstride, int vorder, T - 








xpoints) 








void GetMap{ifd}v (enum target, enum query, T *v) - 
void EvalCoord{12}{fd}[v] (IT coord) - 
void MapGrid1 {fd} (int un, ul, u2) _ 
void MapGrid2{fd} (int un, ul, u2, T vl, T v2) - 
void EvalMesh1 (enum mode, int il, int i2) - 
































void EvalMesh2 (enum mode, int il, int i2, int jl, int 
32) 

void EvalPointl (int i) _ 
void EvalPoint2 (int i, int j) — 























mw Evaluators are not used by many applications other than sophisticated CAD applications. a 


5.2 Selection 


Selection is not supported. 





OpenGL 2.0 Common 
void InitNames (void) — 





void LoadName (uint name) - 





void PushName (uint name) - 





void PopName (void) - 





int RenderMode (enum mode) - 





void SelectBuffer (sizei size, uint xbuffer) - 
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@ Selection is not used by many applications. There are other methods that applications can use to 
implement picking operations. a 


5.3. Feedback 


Feedback is not supported. 





OpenGL 2.0 Common 
void FeedbackBuffer (sizei size, enum type, float *buffer) - 
void PassThrough (float token) - 

















m Feedback is seldom used. 0 


5.4 Display Lists 


Display lists are not supported. 





OpenGL 2.0 Common 
void NewList (uint list, enum mode) — 
void EndList (void) - 
void CallList (uint list) = 
void CallLists (sizei n, enum type, const void «lists) - 














void ListBase (uint base) - 





uint GenLists (sizei range) - 





boolean IsList (uint list) — 

















void DeleteLists (uint list, sizei range) — 





g Display lists are used by many applications — sometimes to achieve better performance and some- 
times for convenience. The implementation complexity associated with display lists is too large for 
the implementation targets envisioned for this specification. Q 


5.5 Flush and Finish 


Flush and Finish are supported. 








OpenGL 2.0 Common 
void Flush (void) VY 
void Finish (void) Vv 














m Applications need some manner to guarantee rendering has completed, so Finish needs to be 
supported. Flush can be trivially supported. Q 
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5.6 Hints 


Hints are retained except for the hints relating to the unsupported polygon smoothing and compression of 
textures (including retrieving compressed textures) features. 













































































OpenGL 2.0 Common 

void Hint (enum target, enum mode) 
target = PERSPECTIVE_CORRECTION_HINT = 
target = POINT_SMOOTH_HINT - 
target = LINE_SMOOTH_HINT - 
target = FOG_HINT - 
target = TEXTURE_COMPRESSION_HINT - 
target = POLYGON_SMOOTH_HINT - 
target = GENERATE_MIPMAP_HINT Vv 
target = FRAGMENT_SHADER_DERIVATIVE_HINT - 








m Applications and implementations still need some method for expressing permissible speed versus 
quality trade-offs. The implementation cost is minimal. There is no value in retaining the hints for 
unsupported features. The PERSPECTIVE_CORRECTION_HINT is not supported because OpenGL 
ES 2.0 requires that all attributes be perspectively interpolated. a 




















Chapter 6 


State and State Requests 


6.1 Querying GL State 


State queries for static and dynamic state are explicitly supported. The supported OpenGL ES state queries 
can be categorized into simple queries, enumerated queries, texture queries, pointer and string queries, and 
buffer object queries. 

The values of the strings returned by GetString are listed in Table 6.1. 


The VERSION string is laid out as follows: 








OpenGL<space>ES<space><version number><space><vendor-specific information> 





The SHADING_LANGUAGE_VERSION string is laid out as follows: 

















OpenGL<space>ES<space><GLSL><space>ES<space><version number><space><vendor-speci 
information> 


The version number either of the form major number.minor number or major number.minor num- 
ber.release number, where the numbers all have one or more digits. The release number and vendor specific 
information are optional. However, if present, then they pertain to the server and their format and contents 
are implementation-dependent. 

As the specification is revised, the VERSION string is updated to indicate the revision. The string format 
is fixed and includes the two-digit version number (X. Y). 
















































































Strings 

VENDOR as defined by OpenGL 2.0 
RENDERER as defined by OpenGL 2.0 
VERSION "OpenGL ES 2.0” 
SHADING_LANGUAGE_VERSION | "OpenGL ES GLSL ES 1.00” 
EXTENSIONS as defined by OpenGL 2.0 





Table 6.1: String State 
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Client and server attribute stacks are not supported by OpenGL ES 2.0; consequently, the commands 


PushAttrib, PopAttrib, PushClientAttrib, and PopClientAttrib are not supported. Gets are supported to allow 
an application to save and restore dynamic state. 





OpenGL 2.0 


void GetBooleanv (enum pname, boolean *params) 


Common 
V 





void GetIntegerv (enum pname, int x*xparams) 


V 





void GetFloatv (enum pname, float *params) 


V 





void GetDoublev (enum pname, double *params) 





boolean IsEnabled (enum cap) 





void GetClipPlane (enum plane, double eqn[4]) 





void GetClipPlanef (enum plane, float eqn[4]) 





void GetLightfv (enum light, enum pname, float *params) 





void GetLightiv (enum light, enum pname, int *params) 








void GetMaterialfv (enum face, enum pname, float *params) 





void GetMaterialiv (enum face, enum pname, int *params) 





void GetTexEnv{if}v (enum env, enum pname, T *params) 





void GetTexGen{ifd}v (enum env, enum pname, T *params) 





void GetTexParameter {if}v (enum target, enum pname, T 
x*params) 





void GetTexLevelParameter{if}v (enum target, int lod, enum 


pname, T *params) 





void GetPixelMap{ui usf}v (enum map, T data) 





void GetMap{ifd}v (enum map, enum value, T data) 





void GetBufferParameteriv (enum target, enum pname, int 


xparams) 





void GetTexImage (enum tex, int lod, enum format, enum 


type, void *img) 





void GetCompressedTexImage (enum tex, int lod, void *img) 





boolean IsTexture (uint texture) 





void GetPolygonStipple (void *pattern) 





void GetColorTable (enum target, enum format, enum type, 
void xtable) 





void GetColorTableParameter{if}v (enum target, enum pname, T 


params) 





void GetPointerv (enum pname, void **params) 





void GetString (enum name) 





boolean IsQuery (uint id) 





void GetQueryiv (enum target, enum pname, int *params) 





void GetQueryObjectiv (uint id, enum pname, int *params) 





void GetQueryObjectuiv (uint id, enum pname, uint *params) 





boolean IsBuffer (uint buffer) 








void GetBufferSubData (enum target, 
sizeiptr size, void xdata) 


intptr offset, 
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OpenGL 2.0 Common 
void GetBufferPointerv (enum target, enum pname, void 
*xparams) 





boolean IsShader (uint shader) 





boolean IsProgram (uint program) 





void GetProgramiv (uint program, enum pname, int *params) 





<ISISTS 


void GetAttachedShaders (uint program, sizei maxcount, 


sizei *count, uint *shaders) 





void GetProgramInfoLog (uint program, sizei bufsize, 


< 


Sizei xlength, char xinfolog) 





iw 


void GetShaderiv (uint shader, enum pname, int *params) 





void GetShaderInfoLog (uint shader, sizei bufsize, sizei 





*xlength, char *infolog) 








void GetShaderSource (uint shader, sizei bufsize, sizei 





xlength, char xsource) 





void GetUniform{if}v (uint program, int location, T 
*xparams) 





void GetVertexAttrib{if}v (uint index, enum pname, T 


xparams) 





void GetVertexAttribPointerv (uint index, enum pname, void 
**xpointer) 

void PushAttrib (bitfield mask) — 
void PopAttrib (void) - 
void PushClientAttrib (bitfield mask) —- 
void PopClientAttrib (void) - 
boolean IsRenderbuffer (uint renderbuffer) 

















void GetRenderbufferParameteriv (enum target, enum pname, 
int x*params) 





boolean IsFramebuffer (uint framebuffer) 





ae 


void GetFramebufferAttachmentParameteriv (enum target, enum 
attachment, enum pname, int *params) 














m There are several reasons why one type or another of internal state needs to be queried by an ap- 
plication. The application may need to dynamically discover implementation limits (pixel component 
sizes, texture dimensions, etc.), or the application might be part of a layered library and it may need 
to save and restore any state that it disturbs as part of its rendering. PushAttrib and PopAttrib can 
be used to perform this but they are expensive to implement in hardware since we need an attribute 
stack depth greater than 1. An attribute stack depth of 4 was proposed but was rejected because 
an application would still have to handle stack overflow which was considered unacceptable. Gets 
can be efficiently implemented if the implementation shadows states on the CPU. Gets also allow an 
infinite stack depth so an application will never have to worry about stack overflow errors. The string 
queries are retained as they provide important versioning, and extension information. O 
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6.2 State Tables 


The following tables summarize state that is present in the OpenGL ES 2.0 specification. The tables also 
indicate which state variables are obtained with what commands. State variables that can be obtained using 
any of GetBooleanv, GetIntegerv, or GetFloatv are listed with just one of these commands - the one that 
is most appropriate given the type of data to be returned. These state variables cannot be obtained using 
IsEnabled. However, state variables for which IsEnabled is listed as the query command can also be obtained 
using GetBooleanv, GetIntegerv, and GetFloatv. State variables for which any other command is listed as 
the query command can be obtained only by using that command. 

State appearing in italic indicates unnamed state. All state has initial values identical to those specified 
in OpenGL 2.0. 





State Queriable | Minimum | Get 
Value 








Begin/end object - = = 





Previous line vertex - - - 





First line-vertex flag - - - 





First vertex of line loop — — — 





Line stipple counter = = = 





Polygon vertices — _ - 





Number of polygon vertices - - _ 





Previous two triangle strip vertices — — a 





Number of triangle strip vertices — - - 





Triangle strip A/B pointer — - — 





Quad vertices — — — 





Number of quad strip vertices - - - 




















Table 6.4: GL Internal begin-end state variables 
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State 


Queriable 


Minimum 
Value 


Get 











CURRENT_COLOR 








CURRENT_INDEX 








CURRENT_T 





EXTURE_COORDS 























CURRENT_NORMAL 





Color associated with last vertex 





Color index associated with last vertex 





tex 


Texture coordinates associated with last ver- 











URRENT_RASTER_POSITION 








URRENT_RASTER_DISTANCE 











URRENT_RASTER_COLOR 








URI 


ERNT_RASTER_INDEX 




















URRENT_RASTER_TEXTURE_COORDS 











QAAITaAIaA;Ia;sSa 





























URRENT_RASTER_POSITION_VALID 








5 








iDG 


FE FLAG 


























Table 6.5: Current Values and Associated Data 


State and State Requests 








State Queriable | Minimum | Get 
Value 











zr 


LIENT_ACTIVE_TEXTURE = = = 








x 
H 




















ERTEX ARRAY _ _ _ 











ERTEX_ARRAY_SIZI 


Gl 
| 
| 
| 











ERTEX_ARRAY_STRIDI 


je] 











ERTEX_ARRAY-_TYP!] 


Gl 
| 
| 
| 














</<|/</)<)</0 








ERTEX_ARRAY_POINTER a _ = 








NORMAL_ARRAY a _ = 





NORMAL_ARRAY_STRIDI 


eal 
| 
| 
| 





NORMAL_ARRAY_TYP 


ts 
| 
| 
| 














NORMAL_ARRAY_POINTER - = = 





FOG_COORD_ARRAY - = = 





{| 


FOG_COORD_ARRAY_STRID! 





FOG_COORD_ARRAY_TYPE - = = 











FOG_COORD_ARRAY_POINTER _ = - 





COLOR_ARRAY = = = 





COLOR_ARRAY_SIZE - = = 





COLOR_ARRAY_STRID 


A 
| 
| 
| 





R. 
R. 
R. 
R. 
R. 
R. 
R. 
R. 


COLOR_ARRAY_TYPE - = = 

















Q 
(e) 


LOR_ARRAY_POINTER - a = 





ECONDARY_COLOR_ARRAY _ = = 





ECONDARY_COLOR_ARRAY-_SIZ 


ts 
| 
| 
| 





ira) 





ECONDARY_COLOR_ARRAY-_TYP 


ts 
| 
| 
| 











R 

R 
ECONDARY_COLOR_ARRAY_STRIDI 

R 

R 











ECONDARY_COLOR_ARRAY-_POINT! 


Gl 
ve) 
| 
| 
| 





NDEX_ARRAY _ _ _ 





DEX-ARRAY-_STRIDI 


CG 
| 
| 
| 





DEX_ARRAY_TYPI 


Gl 
| 
| 
| 








HI HII HI NIN NI NIN 





DEX_ARRAY_POINTER a _ = 








FE XTURE_COORD_ARRAY _ = = 











EXTURE_COORD_ARRAY_SIZI 


Gl 
| 
| 
| 











EXTURE_COORD_ARRAY_STRIDI 


ie) 











EXTURE_-COORD_ARRAY-_TYPI 


| 
| 
| 
| 












































EXTURE_COORD_ARRAY_POINTER _ _ _ 








Table 6.6: Vertex Array Data 


State and State Requests 













































































State Queriable | Minimum Get 
Value 

VERTEX_ATTRIB_ARRAY_ENABLED V False GetVertexAttrib 
VERTEX_ATTRIB_ARRAY_SIZE V 4 GetVertexAttrib 
VERTEX_ATTRIB_ARRAY_STRIDE V 0 GetVertexAttrib 
VERTEX_ATTRIB_ARRAY_TYPE V FLOAT GetVertexAttrib 
VERTEX_ATTRIB_ARRAY_NORMALI ZED JV False GetVertexAttrib 
VERTEX_ATTRIB_ARRAY_POINTER V NULL GetVertexAttribPointer 






































EDGE_FLAG_ARRAY 
EDGE_FLAG_ARRAY_STRIDE - _ = 
EDGE_FLAG_ARRAY_POINTER - - - 
ARRAY _BUFFER_BINDING V 0 GetIntegerv 
VERTEX_ARRAY_BUFFER_BINDING — - - 
NORMAL_ARRAY _BUFFER_BINDING - - - 
FOG_COORD_ARRAY_BUFFER_BINDING - - = 







































































































































































COLOR_ARRAY_BUFFER_BINDING - - - 
SECONDARY_COLOR_ARRAY_BUFFER_— 
BINDING 
TEXTURE_COORD_ARRAY_BUFFER_-— 
BINDING 
ELEMENT_ARRAY_BUFFER_BINDING V 0 GetIntegerv 
VERTEX_ATTRIB_ARRAY_BUFFER_— ‘ 
V 0 GetVertexAttrib 
BINDING 
Table 6.7: Vertex Array Data contd. 
State Queriable Minimum Get 
Value 
BUFFER_SIZE V 0 GetBufferParameteriv 











ww 


BUFFER_USAGE STATIC_DRAW | GetBufferParameteriv 








BUFFER_ACCES 


n 
| 














BUFFER_MAPP] 


eal 
iw) 
| 




















BUFFER_MAP_POINTER = NULL = 











Table 6.8: Buffer Object State 


State and State Requests 








State Queriable | Minimum Get 
Value 








COLOR_MATRIX - = = 








MODELVIEW_MATRIX = _ _ 














PROJECTION MATRIX _ = = 








H 


EXTURE_ MATRIX _ _ _ 











< 
H 
ta 


EWPORT see 2.11.1 | GetIntegerv 














DEPTH_RANGE 0,1 GetFloatv 











COLOR_MATRIX_STACK_DEPTH = = - 














MODELVIEW_STACK_DEPTH = = = 




















PROJECTION_STACK_DEPTH = a = 

















TEXTURE_STACK_DEPTH = = = 














MATRIX_MOD! 


Gl 
| 
| 
| 





NORMALIZE - - - 























RESCALE_NORMAL _ _ _ 














CLIP_PLANE{0-5} - - - 

















CLIP_PLANE{0-5} a - - 




















Table 6.9: Transformation State 





State Queriable | Minimum | Get 
Value 








FOG_COLOR - - - 
FOG_INDI 
FOG_DENSITY = = = 
FOG_START = = = 
FOG 
FOG MODE = 2 = 
FOG - - = 
SHADE_MODEL = — = 





eal 
x 
| 





Gl 











ral 
Zz 
es, 

| 

| 

| 





















































Table 6.10: Coloring 


State and State Requests 
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State 


Queriable 


Minimum 
Value 


Get 








LIGHTING 





COLOR_MATERIAL 








COLOR_MATERTIAL_PARAME 











: 
4 
bz 
Zs) 
| 

















COLOR_MATERIAL_FACE 

















AMBIENT 


material 





DIFFUSE 





material 











SPECULAR 


material 





EMISSION 


( 
( 
( 
( 


material 





SHININES 





S (material 


) 
) 
) = 
) 
) 








LIGHT_ 


KLAMBIENT 











LIGHT _ 





ELLOCAL_VI 


EWER = 











LIGHT 





1 | 














O 
O 
O 
O 


LIGHT _ 








D 

D 
DEL_-TWO_SID 
DI 








EL-COLOR_CONTROL _ 








AMBIENT 


Light,;) 





DIFFUSE 














SPECULAR 


(] 
(Light) 
(light;) 











POSITION (light;) 











CONSTANT 


_ATTENUATION _ 

















sINEAR_A 





TTENUATION 

















QUADRATI 





C_ATTENUATION _ 








SPOT_DIR 








ECTION 











SPOT_EXPONEN 




















SPOT_CUTOFF 





LIGHT{0- 


1 











COLOR_INDEXES 


























Table 6.11: Lighting 


State and State Requests 








State Queriable | Minimum Get 
Value 











POINT_SIZE _ _ _ 











POINT_SMOOTH = a i 














POINT_SPRITE _ _ _ 








POINT_SIZEMIN _ _ _ 














POINT_SIZEMAX _ _ _ 














POINT_FADE_THRESHOLD-_SIZI 





Pl 
| 
| 
| 











POINT_DISTANCE_ATTENUATION a = = 





























POINT_SPRITE_COORD_ORIGIN = = = 





E_WIDTH vA 1.0 GetFloatv 








NE_SMOOTH = = = 











E_STIPPLE_PATTERN _ _ = 

















NE_STIPPLE_REPEAT - = = 























Hi HI] A] Aya 





E_STIPPLE _ = = 











CULL_FACE False IsEnabled 
































JV 
CULL_FACE_MODE v BACK GetIntegerv 
FRONT_FACE JV CCW GetIntegerv 








POLYGON_SMOOTH - = = 





POLYGON_MODE = = = 














POLYGON_OFFSET_FACTOR GetFloatv 








POLYGON_OFFSET_UNITS GetFloatv 








POLYGON_OFFSET_POINT - - = 











POLYGON_OFFSET_LINE _ S 

















POLYGON_OFFSET_FILL VY False IsEnabled 

















POLYGON_STIPPLI 





eal 
| 
| 

















Table 6.12: Rasterization 










































































State Queriable | Minimum Get 
Value 

MULTISAMPLE - - - 

SAMP LE_ALPHA_TO_COVERAGE JV False IsEnabled 

SAMPLE_ALPHA_TO_ONE - - = 

SAMP LE_COVERAGE JV False IsEnabled 

SAMP LE_COVERAGE_VALUE JV 1 GetFloatv 

SAMP LE_COVERAGE_INVERT V False GetBooleanv 






































Table 6.13: Multisampling 
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State Queriable Minimum Get 
Value 











EXTURE_1D _ _ _ 











EXTURE_2D _ _ a 











EXTURE_3D = = = 











FE XTURE_CUBE_MAP _ = = 

















EXTURE_BINDING_1D = = 











EXTURE_BINDING_2D V 





GetIntegerv 








EXTU 











0 
E_BINDING_3D - 0 — 
0 


EXTURE_BINDING_CUBE_MAP JV GetIntegerv 

















EXTURE_CUBE_MAP_POSITIVE_X _ = _ 














EXTU P_NEGATIVE_X > = = 




















EXTU P_POSITIVE_Y = = - 

















EXTU P_NEGATIVE_Y _ > — 














B 
B 
B 
B 








EXTU P_POSITIVE_Z _ _ - 



































PP P| S| YS 


E_CUBE_MAP_NEGATIVE_Z _ - a 

















EXTU 











EXTURE_HEIGH 


| 
| 
| 

















EXTURE_DEPTH - = = 














EXTURE_BORDER - _ me 














EXTURE_INTERNAL_FORMAT = = = 














EXTURE_RED_SIZE _ = = 




















real 
| 
| 
| 























EXTURE BLUE _ SIZE = = re 
EXTU PHA_SIZE > - = 























EXTURE_LUMINANCE_SIZE = = = 




















EXTU 


tz 
| 
H 
W 
r 


NSITY_SIZI 


Gl 
| 
| 
| 

















EXTU 


f= 
| 
is) 
T 
ae) 


TH_-SIZE ae _ 




















EXTURE_COMPRESSED = = = 


























EXTURE_COMPRESSED_IMAGE_SIZE = = = 





























r 


EX TURE_-BORDER_COLOR 




















r. 


EXTURE_MIN_FILTER NEAREST_MIPMAP_LINEAR | GetTexParameteriv 



































EXTURE_MAG_FILTER LINEAR GetTexParameteriv 


E 

















EXTURE_WRAP_S REPEA GetTexParameteriv 











SESE] S 

















EXTURE_WRAP_T REPEA GetTexParameteriv 














EXTURE_WRAP_R 











EXTURE_PRIORITY - = = 














EXTURE_-RES IDENT _ _ _ 

















EXTURE_MIN_LOD = = = 














EXTU 


I 


MAX LOD = = = 

















EXTURE_BASE_LEVEL _ = = 























EXTURE_MAX_LEVEL _ - a 














R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
EXTURE_GREEN_SIZI 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 





EXTURE_LOD_BIAS _ - = 























DEP TH_TEXTURE_MODE = = = 























EXTURE_COMPARE_MODE oa = om 


























BE XTURE_COMPARE_FUNC = = = 






































GENERATE_MIPMAP _ _ _ 








Table 6.14: Texture Objects 


State and State Requests 








State Queriable | Minimum Get 
Value 














EXTUREO | GetIntegerv 





ACTIVE_TEXTURE 4 





W 

















EXTURE_ENV_MODE = = = 


























R 
EXTURE_-ENV_COLOR = = = 
EXTURE_LOD BIAS = = = 
































EXTURE_-GEN_{STRQ} - - _ 











CJ 








EH YER_PLANI 

















OBJECT_PLANE - = _ 








TEXTURE_GEN_MODE = a = 

















COMB INE_RGB -_ = = 











COMBINE_ALPHA = a am 

































































































































































SRC{012}_RGB - - - 
SRC{012}_ALPHA - - - 
OPERAND{012}_RGB - - - 
OPERAND{012} ALPHA - - - 
RGB_SCALE - - - 
ALPHA_SCALE - - - 
Table 6.15: Texture Environment and Generation 
State Queriable | Minimum Get 
Value 

DRAW_BUFFER — - - 
INDEX_WRITEMASK - - - 
COLOR_WRITEMASK J True GetBooleanv 
DEPTH_WRITEMASK JV True GetBooleanv 
STENCIL_WRITEMASK JV 1’s GetIntegerv 
STENCIL_BACK_WRITEMASK V 1’s GetIntegerv 
COLOR_CLEAR_VALUE JV 0,0,0,0 GetFloatv 
INDEX_CLEAR VALUE - - - 
DEPTH_CLEAR_VALUE v 1 GetIntegerv 
STENCIL_CLEAR_VALUE JV 0 GetIntegerv 















































ACCUM_CLEAR_VALUE a = = 











Table 6.16: Framebuffer Control 


State and State Requests 
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State Queriable | Minimum Get 
Value 
SCISSOR_TEST v False IsEnabled 
SCISSOR_BOX V 0,0,w,h GetIntegerv 
ALPHA_TES - - - 
ALPHA_TEST_FUNC - - - 
ALPHA_TEST_REEF - - - 
STENCIL_TEST JV False IsEnabled 
STENCIL_FUNC JV ALWAYS GetIntegerv 
STENCIL_VALUE_MASK V 1’s GetIntegerv 
STENCIL_REE JV 0 GetIntegerv 
STENCIL_FAIL V KEEP GetIntegerv 
STENCIL_PASS_DEPTH FAIL V KEEP GetIntegerv 
STENCIL_PASS_DEPTH_PASS V KEEP GetIntegerv 
STENCIL_BACK_FUNC V ALWAYS GetIntegerv 
STENCIL_BACK_VALUE_MASK V 1’s GetIntegerv 
STENCIL_BACK_REF V 0 GetIntegerv 
STENCIL_BACK_FAIL V KEEP GetIntegerv 
STENCIL_BACK_PASS_ DEPTH FAIL V KEEP GetIntegerv 
STENCIL_BACK_PASS_DEPTH_PASS JV KEEP GetIntegerv 
DEPTH_TEST JV False IsEnabled 
DEPTH_FUNC V LESS GetIntegerv 
BLEND V False IsEnabled 
BLEND_SRC_RGB V ONE GetIntegerv 
BLEND_SRC_ALPHA V ONE GetIntegerv 
BLEND_DST_RGB JV ZERO GetIntegerv 
BLEND_DST_ALPHA V ZERO GetIntegerv 
BLEND_EQUATION_RGB JV FUNC_ADD | GetIntegerv 
BLEND_EQUATION_ALPHA JV FUNC_ADD | GetIntegerv 
BLEND_COLOR V 0,0,0,0 GetFloatv 
DITHER JV True IsEnabled 














INDEX_LOGIC_OP 














COLOR_LOGIC_OP 








LOGIC_OP_MODE 




















Table 6.17: Pixel Operations 


State and State Requests 








State Queriable | Minimum Get 
Value 








UNPACK_SWAP_BYTES _ — _ 








UNPACK_LSB_FIRST - = = 








UNPACK_IMAGE_HEIGHT _ = _ 














UNPACK_SKIP_IMAGES _ _ = 








UNPACK_ROW_LENGTH - = = 








UNPACK_SKIP_ROWS _ = = 





UNPACK_SKIP_PIXELS - _ = 


r 


























7] 


UNPACK_ALIGNMENT V 4 GetIntegerv 














PACK_SWAP_BYTES _ _ = 








PACK_LSB_FIRST - = = 








PACK_IMAGE_HEIGHT = = = 














PACK_SKIP_IMAGES _ _ = 





PACK_ROW_LENGTH = = = 





PACK_SKIP_ROWS _ = = 








PACK_SKIP_PIXELS _ = 














PACK_ALIGNMENT V 4 GetIntegerv 











MAP_COLOR _ = = 





MAP_STENCIL - _ = 











DEX_SHIFT - _ = 








Z 


DEX_OFFSET — = = 





7] 


iD_SCALE - = = 











ys) 


KEN_SCALE — a = 

















JUE_SCALE a _ = 














U 


HA_SCALI 


C 
(t] 














EPTH_SCALI 


[J] 








ED_BIAS - = = 








vs) 


KEN-BIAS - = = 








JUUE_BIAS - = = 











U 


HA_BIAS - = = 


i 











UV) plwlalmlo] >| wlalmyH]H 
Pl 





in| 


PTH-BIAS - — = 

















Table 6.18: Pixels 


State and State Requests 








State Queriable | Minimum | Get 
Value 








COLOR_TABLI 





eal 
| 





POST_CONVOLUTION_COLOR_TABLE _ _ = 











POST_COLOR_MATRIX_COLOR_TABLI 





eal 
| 








COLOR_TABLE_FORMAT - = ss 








COLOR_TABLE_WIDTH - = _ 











COLOR_TABLE_RED_S1IZI 





GI 
| 
| 
| 














COLOR_TABLE_GREEN_SIZE - = _ 


























COLOR_TABLE_BLUE_SIZE = = a 











COLOR_TABLE_ALPHA_SIZI 


Gl 
| 
| 
| 

















COLOR_TABLE_LUMINANCE_SIZE _ = = 




















COLOR_TABLE_INTENSITY_SIZ!I 


5 
E 




















COLOR_TABLE_SCALE - = = 



































COLOR_TABLE_BIAS _ a = 








Table 6.19: Pixels (cont.) 





State Queriable | Minimum | Get 
Value 








CONVOLUTION_1D - = = 





CONVOLUTION_2D - = = 





SEPARABLE_2D = = = 

















CONVOLUTION_BORDER_COLOR = = = 








CONVOLUTION_BORDER_MODE _ = _ 

















CONVOLUTION_FILTER_SCALE - _ _ 














CONVOLUTION_FILTER_BIAS _ = _ 











CONVOLUTION_FORMA - = = 











CONVOLUTION_WIDTH - = = 


















































CONVOLUTION_HEIGH - = = 











Table 6.20: Pixels (cont.) 


State and State Requests 








State Queriable | Minimum | Get 
Value 











POST_CONVOLUTION_RED_SCALE z 7 = 


ve) 











POST_CONVOLUTION_GREEN_SCALE - _ - 














POST_CONVOLUTION_BLUE_SCALE = - _ 

















U 


POST_CONVOLUTION_ALPHA_SCALI 


Gl 
| 
| 
| 








POST_CONVOLUTION_RED_BIAS _ = = 





=] 


POST_CONVOLUTION_GREEN_BIAS _ _ _ 








POST_CONVOLUTION_BLUE_BIAS = = = 






































POST_CONVOLUTION_ALPHA_BIAS _ _ _ 








POST_COLOR_MATRIX_RED_SCALE _ _ _ 














POST_COLOR_MATRIX_GREEN_SCALI 


C] 














POST_COLOR_MATRIX_BLUE_SCALE _ - = 

















POST_COLOR-MATRIX_ALPHA-_SCALI 


Gl 
| 
| 
| 











POST_COLOR_MATRIX_RED_BIAS a _ = 











POST_COLOR_MATRIX_GREEN_BIAS = = = 

















POST_COLOR_MATRIX_BLUE_BIAS = = = 





























POST_COLOR_MATRIX_ALPHA_BIAS = me =. 








HISTOGRA _ - - 





HISTOGRAM WIDTH - - = 





HISTOGRAM_FORMAT _ - = 








HISTOGRAM_RED_SIZE _ = = 














HISTOGRAM_GREEN_SIZE - = = 


25 











HISTOGRAM_BLUE_SIZE - = = 


Gq 














U 


HISTOGRAM ALPHA SIZ! 


GJ 
| 
| 
| 











HISTOGRAM _LUMINANCE_SIZE - a = 


















































HISTOGRAM_SINK _ = = 





Table 6.21: Pixels (cont.) 
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State Queriable | Minimum | Get 
Value 
MINMAX - - - 
MINMAX_FORMAT - - - 
MINMAX_SINK - _ - 
ZOOM_X - - - 
ZOOM_Y - _ _ 
PIXEL_MAP_I_TO_I - - - 
PIXEL_MAP_S_TO_S — = - 
PIXEL _MAP_I_TO_{RGBA} - - - 
PIXEL_MAP_R_TO_R - - - 
PIXEL_MAP _G_TO_G = = - 
PIXEL_MAP _B_TO_B - - - 
PIXEL_MAP_A_TO_A - - - 
PIXEL_MAP_x_TO_y_SIZE - - - 
READ BUFFER - - - 
Table 6.22: Pixels (cont.) 
State Queriable | Minimum | Get 
Value 
ORDER - - - 
COEFF - - - 
DOMAIN - - - 
AP1x«* = = = 
[AP2_x - - - 
AP 1_GRID_DOMAIN - - - 
AP 2_GRID_DOMAIN - - - 

AP 1_GRID_SEGMENTS - - - 
AP2_GRID_SEGMENTS - - - 
AUTO_NORMAL - - - 
Table 6.23: Evaluators 

State Queriable | Minimum Get 
Value 

SHADER_TYPE v - GetShaderiv 

DELETE_STATUS Vv False GetShaderiv 

COMPILE STATUS t False GetShaderiv 

INFO_LOG_LENGTH t 0 GetShaderiv 

SHADER_SOURCE_LENGTH t 0 GetShaderiv 











Table 6.24: Shader Object State 


State and State Requests 


























































































































State Queriable | Minimum Get 
Value 
CURRENT_PROGRAM JV 0 GetIntegerv 
DELETE_STATUS J False GetProgramiv 
LINK_STATUS JV False GetProgamiv 
VALIDATE_STATUS V False GetProgramiv 
ATTACHED_SHADERS JV 0 GetProgramiv 
INFO_LOG_LENGTH JV 0 GetProgramiv 
ACTIVE_UNIFORMS J 0 GetProgamiv 
ACTIVE_UNIFORM_MAX_LENGTH JV 0 GetProgramiv 
ACTIVE_ATTRIBUTES JV 0 GetProgramiv 
ACTIVE_ATTRIBUTES_MAX_LENGTH JV 0 GetProgramiv 
Table 6.25: Program Object State 
State Queriable | Minimum Get 
Value 











VERTEX_PROGRAM_TWO_SID! 





eal 
| 











URRENT_VERTEX_ATTRIB 4 0,0,0, 1 Get VertexAttributes 


O 





























VERTEX_PROGRAM_POINT_SIZI 





real 
| 




















Table 6.26: Vertex Shader State 





State Queriable | Minimum Get 
Value 











PERSPECTIVE_CORRECTION_HINT - - - 
POINT_SMOOTH_HINT - - - 
LINE_-SMOOTH-_HINT - - - 
POLYGON_SMOOTH_HINT - - - 
FOG_HINT - - - 
GENERATE_MIPMAP_HINT JV DONT_CARI GetIntegerv 
TEXTURE_COMPRESSION_HINT - - - 
FRAGMENT_SHADER_DERIVATIVE_HINT - - — 
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Table 6.27: Hints 
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State Queriable | Minimum Get 
Value 
AX_LIGHTS - - - 
AX_CLIP_PLANES - - - 
AX_COLOR_MATRIX_STACK_DEPTH - - - 
AX_MODELVIEW_STACK_DEPTH - - - 
AAX_PROJECTION_STACK_DEPTH - - - 
AAX_TEXTURE_STACK_DEPTH - - - 
SUBPIXEL_BITS v 4 GetIntegerv 
AX_3D_TEXTURE_SIZE - - - 
MAX _TEXTURE_SIZE JV 64 GetIntegerv 
AAX_CUBE_MAP_TEXTURE_SIZE JV 16 GetIntegerv 
AX_PIXEL_MAP_TABLE - - - 
AX_NAME_STACK_DEPTH - - - 
AX_LIST_NESTING - - - 
AX_EVAL_ORDER - - - 
AX_VIEWPORT_DIMS JV see 2.11.1 | GetIntegerv 
AAX_ATTRIB_STACK_DEPTH - - - 
AAX_CLIENT_ATTRIB_STACK_DEPTH - - - 
Maximum size of a color table - - - 
Maximum size of the histogram table _ - - 
AUX_BUFFERS - - - 
RGBA_MODE - - - 
INDEX_MODE - - - 
DOUBLEBUFFER - - - 
ALIASED_POINT_SIZE_RANGE J 1,1 GetFloatv 
SMOOTH_POINT_SIZE_RANGE - - - 
SMOOTH_POINT_SIZE_GRANULARITY = 7 = 
ALIASED_LINE_WIDTH_RANGE VY 1,1 GetFloatv 
SMOOTH_LINE_WIDTH_RANGE - - - 
SMOOTH_LINE_WIDTH_GRANULARITY _ - - 
MAX_CONVOLUTION_WIDTH - = = 
MAX_CONVOLUTION_HEIGHT - - - 
MAX_ELEMENTS_INDICES - - - 
MAX_ELEMENTS_VERTICES - - - 
SAMP LE_BUFFERS v 0 GetIntegerv 
SAMPLES JV 0 GetIntegerv 
COMPRESSED_TEXTURE_FORMATS JV - GetIntegerv 
NUM_COMPRESSED_TEXTURE_FORMATS J 0 GetIntegerv 
SHADER BINARY_FORMATS JV - GetIntegerv 
NUM_SHADER_BINARY_FORMATS JV 0 GetIntegerv 
SHADER_COMP TILER JV False GetBooleanv 
QUERY_COUNTER_BITS - - - 
EXTENSIONS v - GetString 
RENDERER v - GetString 
SHAD ING_LANGUAGE_VERSION V - GetString 
VENDOR v - GetString 
VERSION v - GetString 








Table 6.28: Implementation Dependent Values 


State and State Requests 




























































































































































































































































































State Queriable | Minimum Get 
Value 
AX_TEXTURE_UNITS - - - 
AX_VERTEX_ATTRIBS V 8 GetIntegerv 
AX_VERTEX_UNIFORM_ VECTORS V 128 GetIntegerv 
AX_VARYING_VECTORS V 8 GetIntegerv 
AX_COMBINED_TEXTURE_IMAGE_- y g Geihatexery 
UNITS 
AX_VERTEX_TEXTURE_IMAGE_UNITS JV 0 GetIntegerv 
AX_TEXTURE_IMAGE_UNITS V 8 GetIntegerv 
AX_TEXTURE_COORDS - - - 
AX_FRAGMENT_UNIFORM_VECTORS JV 16 GetIntegerv 
AX_DRAW_BUFFERS - - - 
AX_RENDERBUFFER_SIZE v 1 GetIntegerv 
Table 6.29: Implementation Dependent Values (cont.) 
State Queriable | Minimum Get 
Value 
RED_BITS v - GetIntegerv 
GREEN_BITS v - GetIntegerv 
BLUE_BITS v - GetIntegerv 
ALPHA BITS V - GetIntegerv 
INDEX_BITS - - - 
DEPTH_BITS v 16 GetIntegerv 
STENCIL_BITS v 8 GetIntegerv 
ACCUM_BITS - - - 
IMP LEMENTAT ION_COLOR_READ_TYPE v = GetIntegerv 
IMP LEMENTATION_COLOR_READ_- y _ Gethitenery 
FORMAT 




















Table 6.30: Implementation Dependent Pixel Depths 
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State Queriable | Minimum Get 
Value 

LIST_BASE - - 

LIST_INDEX - - 

LIST_MODE - - 

Server attribute stack - - 

ATTRIB_STACK_DEPTH - - 

Client attribute stack — - 

CLIENT_ATTRIB_STACK_DEPTH - - 

NAME_STACK_DEPTH - — 

RENDER_MODE - - 

SELECTION_BUFFER_POINTER 7 = 

SELECTION_BUFFER_SIZE - - 

FEEDBACK_BUFFER_POINTER - _ 

FEEDBACK_BUFFER_SIZE - - 

FEEDBACK BUFFER_TYPE - - 

CURRENT_QUERY - - 

Current error code(s) NO_ERROR | GetError 

Corresponding error flags - - 

Table 6.31: Miscellaneous 
State Queriable | Minimum Get 
Value 

RENDERBUFFER_BINDING JV 0 GetIntegerv 
RENDERBUFFER_WIDTH JV 0 GetRenderbufferParameteriv 
RENDERBUFFER_HEIGHT V 0 GetRenderbufferParameteriv 
RENDERBUFFER_INTERNAL_FORMAT J RGBA4 GetRenderbufferParameteriv 
RENDERBUFFER_RED_SIZE JV 0 GetRenderbufferParameteriv 
RENDERBUFFER_GREEN_SIZE V 0 GetRenderbufferParameteriv 
RENDERBUFFER_BLUE_SIZE JV 0 GetRenderbufferParameteriv 
RENDERBUFFER_ALPHA_SIZE V 0 GetRenderbufferParameteriv 
RENDERBUFFER_DEPTH_SIZE V 0 GetRenderbufferParameteriv 
RENDERBUFFER_STENCIL_SIZE V 0 GetRenderbufferParameteriv 








Table 6.32 


: Renderbuffers State Variables 
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State Queriable | Minimum Get 
Value 
FRAMEBUFFER_BINDING JV 0 GetIntegerv 
FRAMEBUFFER_ATTACHMENT_OBJECT_— 
fate) JV NONE GetFramebufferA ttachmentParameteriv 
FRAMEBUFFER_ATTACHMENT_OBJECT_- ; 
ae Vv 0 GetFramebufferA ttachmentParameteriv 
FRAMEBUFFER_ATTACHMENT_-— 
V 0 GetFramebufferA ttachmentParameteriv 
EXTURE_LEVEL 
FRAMEBUFFER_ATTACHMENT_— 
JV +ve X face | GetFramebufferAttachmentParameteriv 
EXTURE_CUBE_MAP _FACE 












































Table 6.33: Framebuffer State Variables 





Appendix A 


Deleting Shared Objects 


This section clarifies how object deletion works for texture, buffer, framebuffer and renderbuffer objects. 
This section will only refer to texture objects but the same rule applies to buffer, renderbuffer and frame- 
buffer objects. 

The OpenGL 2.0 specification states that after a texture object is deleted, it has no contents or dimen- 
sionality, and its name is again unused. However, the EGL specification states that all modifications to 
shared context state as a result of executing g\BindTexture are atomic. Also, a texture object will not be 
deleted until it is no longer bound to any rendering context. 

An ambiguity arises because the OpenGL ES specification indicates that texture names are immediately 
unused after deletion, but the EGL specification indicates deletion does not actually occur until the texture 
is unbound from all contexts. Reading only the OpenGL and OpenGL ES specifications may lead one to 
conclude that a call to DeleteTextures marks a name as unused immediately, regardless of whether a texture 
object is bound in other contexts, but reading the EGL specification in conjunction with the OpenGL ES 
specification may lead one to believe that the name remains used until the texture is explicitly unbound in 
all contexts. 


A.1_ Effect of shared object deletion on object namespace 


After DeleteTexture is called, the object names are immediately marked unused. Note that the actual under- 
lying object state and data are retained (i.e. the object state is orphaned) and the object remains bound to all 
contexts until that object is explicitly unbound by a given context, or the context itself calls DeleteTexture 
which does an implicit Bind to object 0. 

Let us review the effect on IsTexture in the following scenario: 


1. Context 1 binds texture T to the 2D texture target 
2. Context 2 binds texture T to the 2D texture target 
3. Context 1 deletes texture T 


4. Context 1 (or context 2) asks IsTexture(T) 


IsTexture will return FALSE. 





The used vs. unused state of the texture name T affects whether or not a new object is created on a bind 
of texture T. To see this, consider another scenario: 
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1. Context 1 binds texture T to the 2D texture target 
2. Context 2 binds texture T to the 2D texture target 
3. Context 1 deletes texture T 


4. Context 2 attempts to rebind to texture T to the 2D texture target 


When context 2 attempts to rebind to texture T in step 4, context 2 successfully creates and binds a new 
uninitialized 2D texture with the name T. 

The choice of behaviors also affects the generation of OpenGL ES errors. The OpenGL ES specification 
states that it is an error to bind a texture to a target if that texture has already been bound to a target of a 
different type. So, consider the following scenario: 


1. Context 1 binds texture T as a 2D texture 
2. Context 2 binds texture T as a 2D texture 
3. Context | deletes texture T 


4. Context 1 attempts to rebind to texture T as a 3D texture 


Context 1 successfully binds texture T to the 3D texture target creating a new uninitialized 3D texture in 
the process. Additionally, after step 4, if context 2 were to query its current texture bindings, it would find 
out that it is bound to a 2D texture named T, even though the texture named T is now a 3D texture. Further, 
if context 2 attempted to rebind texture T to the 2D target, then it would get an error. 


A.2. Sharing objects across multiple OpenGL ES contexts 


This section defines some of the behavior of OpenGL ES objects which can be shared by multiple contexts. 
Objects which can be shared in this manner include: 


e textures 
e buffer objects 


renderbuffers 


framebuffers 


Traditionally, the specification of shared object and multi-context behavior was left to the window- 
system. However, this section describes the portions of behavior of shared objects that apply to all OpenGL 
ES implementations, regardless of window-system. 
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A.2.1_ Updates to the state of shared objects 


When multiple contexts are bound to a shared object, such as a texture, vertex buffer object etc., care 
should be taken to ensure that multiple contexts do not change the state of the shared object simultaneously. 
Otherwise, it is undefined which set of state changes made by the various contexts will take precedence. 

Further, even if only one context at a time changes the state of the shared object, it is possible that the 
other context’s might not observe the changed state until the next time those contexts bind the shared object 
again. 

Finally, it is guaranteed that outstanding changes to the state of a shared object must be observable by 
any context which binds that object. 

In other words, if context A and context B, are bound to shared object O, and context A modifies the 
state of shared object O, then it is possible that context B will still be using an out of date version of objection 
O that does not reflect the state changes until context B rebinds object O. Further, it is guaranteed that the 
state changes made by context A will be observable by context B when context B binds object O. 


A.2.2 The effect of shared object deletion on object namespace 


If multiple contexts are bound to a shared object, such as a texture, vertex buffer object etc., then care 
should be taken when deleting that shared object. This is because after deletion of a shared object bound to 
multiple contexts the name of the deleted object is immediately marked unused. This in turn means that the 
name can immediately be used by any context to create a new object with that name and the name might be 
returned by OpenGL ES routines which generate ranges of object names. However, the underlying object 
state and data may still be in use by contexts other than the context which deleted the object. These other 
contexts might continue using the underlying object, and these other contexts might still contain state which 
identifies the named object as being currently bound, until those other contexts make another attempt to 
bind the object with that name. Since the name is immediately unused, attempts to bind an object of that 
name by any context will create a new object with the specified name. 
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Appendix C 


Document History 


Version 2.0.25, updated 2010/11/02 


e Include GetShaderSource in the table of program object-related commands in section 2.15.3 (Bug 
37/53): 


Version 2.0.24, updated 2009/04/01 
e Fixed token naming in table 6.33 (bug 790). 


e Added live link to the extension registry in appendix D. 


Version 2.0.23, updated 2008/08/27 


e Bump release number to 2.0.23 for public release. 


e Flip sign of log2(€) in computation of precision for GetShaderPrecisionFormat (bug 3667). Duplicate 
some additional language from the full spec for the same command. 


Version 2.0.22, updated 2008/08/06 

















e Remove BUFFER_ACCESS and BUFFER_MAPPED state (bug 3449). 
e Minor changes to prototypes and error conditions of ShaderBinary (bug 3673). 
e Removed luminance color buffer formats from CopyTexImage conversion table (bug 3695). 


e Minor fixes to prototypes and error conditions of framebuffer object commands (bug 3693). Change 
initial value of RENDERBUFFER_INTERNAL_FORMAT to RGBA4 in state table (bug 3693). Use Get- 
FramebufferAttachmentParameteriv instead of GetFramebufferParameteriv in state tables. 

















e Clarify meaning of returned values from GetShaderPrecisionFormat (bug 3667). 


Version 2.0.22, updated 2008/07/17 


e Rewrote description of GetShaderPrecisionFormat (see section 2.15) to match full spec and clarify 
meaning of range and precision values returned (bug 3667). 


Version 2.0.22 First version of the Full Specification. 
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Appendix D 


OES Extensions 


OpenGL ES extensions that have been approved by the Khronos OpenGL ES working group are described 
in this chapter. These extensions are not required to be supported by a conformant OpenGL ES implementa- 
tion, but are expected to be widely available; they define functionality that is likely to move into the required 
feature set in a future revision of the specification. 

In order not to compromise the readability of the core specification, OES extensions are not integrated 
into the core language; instead, they are made available online in the OpenGL ES Extension Registry. 
Extensions are documented as changes to the Specification. The Registry is available on the World Wide 
Web at URL 


http://www.khronos.org/registry/gles/ 


D.1 Naming Conventions 


To distinguish OES extensions from core OpenGL ES features and from vendor specific extensions, the 
following naming conventions are used: 


e A unique name string of the form ”GL_OES name” is associated with each extension. If the extension 
is supported by an implementation, this string will be present in the EXTENSIONS string. 


e All functions defined by the extension will have names of the form FunctionOES. 


e All enumerants defined by the extension will have names of the form NAME_OES. 


D.2. Promoting Extensions to Core Features 


OES extensions can be promoted to required core features in later revisions of OpenGL ES. When this 
occurs, the extension specifications are merged into the core specification. Functions and enumerants that 
are part of such promoted extensions will have the OES affix removed. 

OpenGL ES implementations of such later revisions should continue to export the name strings of 
promoted extensions in the EXTENSIONS string, and continue to support the OES-affixed versions of 
functions and enumerants as a transition aid. 
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